3 Simple Rules That Will Make You a 'Superstar' Developer | Hacker News Reader

3 Simple Rules That Will Make You a 'Superstar' Developer

coderoom.wordpress.com

52 pointsmoconnor26 comments

A smart accountant once told me that the answer to "How much money did you make?" is always, "Who wants to know?" If it's an investor, the answer is "A lot." If it's a customer, the answer is "A little." If it's the IRS, the answer is "None."

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 deserves it's own blog post.

Why? He made his point in much less space here.

Because a lot more people would probably see it.

This is, by far, a much more enlightened post than the article in the submission.

"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 :(

Agreed. Similar instance, used to work with this great developer. He was very talented, friendly, etc. Used to pair with him every day and he challenged me constantly to improve. He also tried to challenge the rest of the team, questioning the way we did things and suggesting ways to improve. He collided with a few guys who'd been there longer. Layoffs came around and he got canned. Now though, he's better off and works at a place that encourages continual improvement.

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.

Sounds like sour grapes over bad team members being considered "superstars" by incompetent management. What the appeal of these bitter sarcastic articles? If you have a problem with a colleague, passive-aggressely blogging about it is going to serve no one, least of all yourself.

I just posted a comment similar to yours. I browsed over the comments here really fast to be sure no one said exactly what I did first, but I must have overlooked yours. I do not understand the appeal to do this either. It seems a bit pretentious in a way to make satirical articles such as the ones demonstrated here.

It just may be the killer app of Twitter though, now that I think about it.

I think that you are missing the point of this satire. The rant doesn't seem to be directed to other people as much as the younger version of the author.

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.

Re: Just rewrite the lot as you think it ought to work. Call it refactoring if anyone asks.

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.

"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." -- Quote at the end of the post

I am beginning to dislike articles such as this. Satire every once in a while is fine, but if you have nothing positive to contribute during it, I really do not find it fun or interesting. I did not get much out of this article in terms of entertainment or knowledge even though it appears to be positioning itself to try to do both.

What about the developer that is considering the readability of the file AS A WHOLE? They would also fit under this category as they tend to re-jig/re-write/refactor a lot of code.

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.

Benefit 2: Although you’ll introduce lots of new bugs like this, it’ll be several months before they start showing up, by which time your reputation as an expert programmer will already be assured. I've seen a lot of people trying this approach but no one of them succeeded :D

I don't know. Unless anyone actually tells me this person is in fact a "superstar developer" I may not believe it.

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.

I think you've missed the satirical nature of the article...

I think you missed something.

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.

Awww Damn. I hate when I'm the idiot =/

While I know this work was satire, in some cases, it is advised to leave out comments in code. While some comments are necessary, they should exist merely to state what the code does not. The best written code often explains itself through easy to read layout, variable naming, and intelligent function and class development procedures. If the code already says what it is doing, there is no reason to repeat it in a comment. A good programmer is always trying to write code like this.

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.

Its his page on the net and he is clearly venting , that's his right.

However, this is nothing new and has been there in various forms for ages , HN could do without this submission.

I like Uncle Bob's rule: Leave the code in just a little bit better condition as when you checked it out. If everyone does that, it does wonders over time.

Can get you fired if you have a smart boss.

I really hope that this author is portraying sarcasm at the expense of so-called 'superstar' developers that are on his/her team.

He does italicize a postscript at the bottom of the article indicating it's satire.

Reply on news.ycombinator.com