Hacker News new | ask | show | jobs
by RutZap 4703 days ago
I would say that ego is something that every good programmer should have. It's not about being a rockstar or not. It's all about the code. This is what mainly defines programmers/coders/developers/makers.

It is always about the code and it's never not about the code. Having the ego to believe that your code is the best makes you a good programmer; because, inevitably, somebody will come and point out that there's a bug, a flaw in your beloved creation. That's when you get annoyed, your ego is crushed... you accept it and the next time you won't mess up again. That's how you improve your skills and that's how you get to be a better developer.

You shouldn't care if you're called a rockstar or not, and most certainly you shouldn't call yourself one; saying that you're a programmer should be enough! We should live in the shadows and let our code to do the talking.

PS: I have the feeling that "rockstar" programmer is starting to replace the beloved "guru" as the word that makes up for one's lack of coding skills

2 comments

> Having the ego to believe that your code is the best makes you a good programmer

I disagree. Whenever I am asked by somebody what the worst code they have seen lately is, I always point to my own hall of shame. Ego builds a wall around you and makes being a teammate more difficult. You essentially become unapproachable by management, and worse, by junior devs looking for guidance.

You don't have to have your pride crushed to learn. Just accept that there are other smart(er) people around you and seek advice rather than incite it.
They don't even have to be smarter, they just happen to notice errors you make. Often that comes from you being too close to the code, akin to the "obvious" errors others find when you ask them to double check some prose you just wrote.

I handle this by accepting that I'm a fallible human being and that the artifacts that we're constructing are way too complicated to always get right the first time. So errors in my work, as long as they're reasonably small in number, are just a reflection of that fallibility and complexity (if the number is too big that's a signal something is seriously wrong).