I am scared of publishing my code as open source! I feel inferior, what should I do?

Hi, dev community,

I am a junior developer and I have made a couple of jQuery plugins. If I open source it, it will help me create a good developer profile. However, I fear negative reviews from the developers worldwide. I fear my code is not up to the standards. What should I do?

Comments (12)

Mark's photo

You should post your code especially if you're unsure about it!

If someone sees something to improve and leaves a comment, they'll probably say what you should do instead, perhaps even why. That's pretty much the perfect way to learn!

I don't think it's likely they'll leave mean unconstructive comments, but if anyone does you can safely assume he's an asshole and can be ignored.

If you're really worried you can make two Github accounts, one for code you're more confident about and will include on your CV. But I wouldn't recommend it - you'll always be unsatisfied about code after a few years, that's not exclusive to juniors.

(Practically speaking, it's not likely that many people will look at the code close enough to leave any remark.)

Jason Knight's photo

Now, word of warning, I don't sugar coat things, I'm not gonna slap the rose coloured glasses on your head, blow smoke up your backside, and give you disingenuous soothing syrup words.

To be brutally frank, if you're "feeling inferior" or "scared" about your code, that's EXACTLY the time to have others looking at it!!! When others are critical LISTEN instead of packing up your toys like a child and running home to mommy.

You NEED negative feedback -- no matter how bad -- to get better! Don't practice alone, it only embeds your errors!

When someone says something negative, REGARDLESS of how it's being said, RESEARCH what they are telling you. Weigh the pro's and con's. Learn, adapt. DEAL WITH IT!!!

Mind you, said feedback has to have substance... It's ok for someone to say it sucks if they say WHY it sucks. That's how you separate the wheat from the chaff on feedback. If they use a term you don't know, RESEARCH it to find out what they are talking about -- FAR too many people right now take even the slightest negative feedback as a personal attack -- and that's BULLSHIT if there's actual advice being given... and if you don't understand the advice, LEARN!

Computing is an industry where on the hardware side three years is obsolete, five years is the scrapheap. Software is LUCKY if it can see double those numbers, and sometimes it's half that if you deal with anything security related.

So if you're not ready to change, keep learning, keep improving, and get feedback from others, you might as well just pack it in now. Otherwise, man up, take your punches, and get it done!

Show all replies
Josh Montgomery's photo

I think what Ingmars Lazdins is saying is that there are constructive ways to offer criticism and there are non-constructive ways to deal with criticism. Being nice to someone (whether or not you know them) is NOT the same thing as bull-shitting people (at least, not most of the time, there are always exceptions). If I had asked this question and got your response, I would immediately ignore it. Not because I'm soft or weak or whatever, but because you do come off in a negative light, and it doesn't do anything for me.

I actually feel bad for you that you consider people being tactful is a sign of an alternative motive. There's enough negativity in this world, why add to it if you don't need to (this is coming from my hippie side I suppose)? There is very little difference in the overall message between your response and Marcos...

Marco Alka's photo

Hello Anon,

thank you for reaching out to us with your concerns. Writing code is always difficult, and requires experience. The only way to become better is by training it.

You say, you are a junior dev. You say that your concern is that your code is not good and that you have deficits. That's ok. It's the same for all of us. I often feel that my code is inferior, especially when working with Rust, a language which I still am a newby at. The important part is that you are prepared to receive review and have the drive to improve. And that's the most important thing and what others will respect about you. If you are eager to improve, people will want to help you do so.

Opensourcing code will not magically get people to review your code, but it will at least enable others to actually do so. You could opensource one of your smaller plugins, which you feel confident about, on GitLab or GitHub, and then ask in dev-communties (like Hashnode) for reviews of the code. Ask the community nicely to state their opinion of the style, where they see problems and ways to improve the code. For a small code base, people will likely help you and leave comments, and those comments will show you how to improve. You do not have to opensource everything at once. Gradually learn by what your peers have to say :)

Especially Hashnode already has a record of review-questions, however often just asking for ways to improve a code snippet. Using Hashnode search you can verify that the community comes up with interesting solutions and positive answers to such review questions and sometimes even discussions arise which help other people, too. Check out the following discussions for reference:

Ben Buchanan (200ok)'s photo

If they work, publish them :) If you get heaps of negative feedback without anything constructive, you can always take it down again. But you might get positive and constructive feedback. You can only be sure that not publishing will lead to no feedback.

Josh Montgomery's photo

I say go ahead and post it, the majority of developers out there have been through exactly what you are going through, and hopefully will be respectful enough to only offer constructive criticism. This is how we (coders) learn our craft, we create something, share it with others, and then use whatever feedback to better ourselves.

Google "Imposter Syndrome" and you'll get a better understanding of what you're going through.

Arihant's photo

Let me tell you my open source story. In 2016, the Director of Backend Engineering at my company, who was also in my team suggested all us new kids, that we need to jump on any idea we might have and work on it. We were, as some of us Indians fondly like to say, dhadh hee (too) excited on that and the next coming days. One of my kid colleagues (kid = junior dev) made this really helpful node module called npm-install-all. It was a simple idea that came out of the frustration to keep track of whether a needed node module had been added to package.json file after playing around with it and deciding that it was needed (this was before the days when npm install <some package> automatically added it to package.json file). He was the first one of us who solved some problem that he was having.

But that time, all I saw was

Whoa! He made a node module! This is his open source starter. I should do something soon lest I never be able to do anything.

Then I had this idea, which at that time nobody had done right โ€” While trying to debug with console.logs sometimes we need demarcation lines between two logs for visible separation so that we know where one log ends and the other starts. What I intended to do was not just make a generic module that would enable people to do so easily, but also to make those separators (for example simple horizontal line like โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”โ€”), adjust to change in the terminal size. I gave up on that module way to early.

It wasn't until a couple of weeks back that I had another idea for a node module. So I'm creating a twitter bot where I needed to dynamically create twitter threads from a long string (basically just split a long string into allowed tweet size array of strings). So I looked around to see if there were any node modules to do that. There weren't. I decided to pick that up and make it .

I coded it up in a couple of days and published it. Then a day later, to my horror, I realised that I had completely fudged it up! It was a disastrously wrong implementation. To another horror, I had written tests for the first time in my life, and the tests were as good as nothing. They were wrongly written as well.

So I started writing the node module again, from scratch, and realised that it wasn't as easy as it sounded initially, there were too many edge cases to take care of. 3 days later, the node module was done, with tests written for it, which actually tested something useful. And then I published it!

My point of writing this whole story is that, I can't tell you (literally can't tell you, because it'll take up too much time) to enumerate all the things that I learnt from writing this node module. But trying to summarise โ€”

  1. I learnt some ES6 features I hadn't every used before.
  2. I used esm node module for using ES6 imports and exports module system
  3. I learnt how to return early to save confusing else and else if statements.
  4. I coded up the node module in javascript. I had to do so many type checks in my code, and even in my tests. I realised for the first time, why statically typed languages like Typescript would be beneficial and would save immense amount of otherwise testing and debugging time
  5. I learnt how to brainstorm first on notepad and properly get the architecture of how things need to be implemented before jumping into writing code.
  6. I learnt how to write tests (as I said, I had not written any tests before for any project)
  7. I learnt how to set up a basic travis build system to automatically run tests for different node versions.
  8. I learnt how to make the node module visually appealing by writing proper API docs and putting up a cool logo.
  9. I learnt how to depreciate old versions of the package (because I had published the wrong implementation as I said above).

I could do all of these like an important exam preparation โ€” because I knew my node module might be beneficial for many people out there, I spent extra time in making it and testing it properly, so that it could be as useful to people as it would be for me. And more so, so that people could chip in and open an issue for a bug, or for general advice about the code or anything. It's always good to get feedback (see how much feedback I got for a pull request that I made for a popular google extension).

The best thing about open source is that most people mean well and are friendly. Wanting to open source something would push you to maintain it, if not for people then for yourself, in case no one else uses it. At least you'd get to learn a lot โ€” worst case scenario. Best case scenario? You'll get feedback and get to collaborate with people and learn even more. So what is that you are afraid of now? Chime right in! Open source it properly! Hope this helps!

Ingmars Lazdins's photo

If You feel that Your particular code can help someone other, then OS it. Do not fear criticism, in fact it can be a super valuable source of 3rd party insight. True DEVS learn from mistakes, not from successes ;)

Flavio Copes's photo

I think it's very beneficial having your code in the public. No one is going to rush and read your code and shame you publicly with their own opinion on why your code sucks and theirs is better.

The only thing that might happen is, some people might contribute with pull requests and issues that actually improve your plugins code and all your future code as well, as you learn from your mistakes. No code is ever written "up to the standards" from zero. Also, there is no "standards" police.

I spent 2 years working full-time in the total public on open source code and while that was stressful from a point of view, it was a great learning experience, thanks to the feedback I received.

So go on!