Same thing here. The answer to "Who is a superstar developer?" is always, "Who wants to know?"
To a project manager, the programmer who hits every deadline (regardless of quality) is a superstar.
To a customer, the programmer who solves their problem quickest is a superstar.
To a business owner, the programmer who makes them the most money is a superstar.
To a PHB, the programmer who makes them look the best is the superstar.
To a journalist, the programmer who tells the best stories is the superstar.
To a junior programmer, the best mentor is the superstar.
To another programmer, the programmer they are most likely to want to go into battle with is the superstar.
This is true, my company recently fired the programmer I most respected. His code was elegant, reusable, always well thought out. However he wasn't good at estimating how long something would take him, and after missing a few important deadlines they canned him :(
Sometimes though, the "who is a superstar" becomes "who is your competition" and then it becomes a negative. At least when competition is feared instead of seen as a challenge.
A lot of young developers who are smart and well meaning have the tendency to behave in a way equivalent to following the three rules... Their environment gives them very strong incentives. After all, who doesn't want to be popular among his colleagues and appreciated by his boss? They mean no harm and they may genuinely care about their project, but they end being destructive.
I am not saying I am smart (I am rather young and well meaning, and I am a developer though) and I recognized in some of the described behaviors myself from a couple of years ago. And, well, it was indeed bitter.
I have worked on a couple of projects, with great people, and NOW I know better than to rush to refactor the hell of some piece of code that works just because doesn't quite live to my high esthetic standards or stylistic preferences. However, I didn't see the light immediately. If I had had a chance to read that article, say, 3 years ago, I would probably have been less of a PITA for my colleagues and the world would have been a better place. Better introspection usually leads to more effective behavior (at least unless you are a genuine jerk, but then your refactoring frenzy is the least of two serious problems your colleagues have).
I hope to meet a lot of smart, young developers in the coming years, and I am pretty sure that at least some of them will be right in the "it isn't beautiful, let's refactor, RIGHT NOW!!!" phase. I will be able to send them a link to that blog post, and that is really awesome.
I recently worked on someone else's code that was... terrible. Just really terrible. State information was stored as strings like "B13" to indicate that you are in part B step 13, everything was driven by line after line of twisty nested if statements.
My first inclination was to rewrite everything. I could have cut the size of the code in half, maybe more - but this was an existing, working system. Sometimes the right decision is to rewrite everything, but sometimes the right decision is to fix only what's broke. It takes experience to tell which situation you're in.
I find quite a few developers on the team I'm working on fix bugs without considering the overall readability of what is going on, making the code harder and harder to read with each fix.
Rule 3: Don’t take time to document your code, or add little comments explaining potential pitfalls in modifying some of the less clear statements you’ve introduced. You don’t need them, you wrote the code.
Gosh. I understand the rule "Code is twice as hard to debug as it is to code, so never code as cleverly as possible" because one wont be able to debug his or her own code, but saying no comments? I do NOT know the structure of the program I made five years ago. If there were no comments, it would take me a little while to edit something- build in a feature, ect. Who the fuck says you need to stop documenting to become a superstar developer? Not even that. It's one of the three rules to becoming a superstar developer? I can't believe it is true. I see so many things wrong with the statement.
Postscript for the naive: This post is a mild satire on programming in teams. These three rules, while undoubtedly effective, are evil. They harm overall project progress for your own benefit. They don’t make you a better programmer intrinsically, only compared to the rest of your team. You may, like I and countless others, have done something like this completely innocently in the past, when you didn’t know better. Now you know better.
As for having a set of rules to become a superstar developer... you would need to actually be a superstar developer to make the rules. If they are extremely rare, we should rarely have any rules because there would be few people posting such rules. Therefore, I am skeptical of any such lists unless they are from someone I recognize as extremely gifted prior to the writing of the rules.
However, this is nothing new and has been there in various forms for ages , HN could do without this submission.