

3 Simple Rules That Will Make You a 'Superstar' Developer - moconnor
http://coderoom.wordpress.com/2010/01/28/3-simple-rules-that-will-make-you-a-superstar-developer/

======
dasil003
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.

~~~
Freebytes
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.

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

------
edw519
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.

~~~
jseifer
This deserves it's own blog post.

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

~~~
jseifer
Because a lot more people would probably see it.

------
xsmasher
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.

------
DavidPP
"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

------
Freebytes
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.

------
Quarrelsome
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.

------
drtse4
_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

------
dbz
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.

~~~
Proleps
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._

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

------
ivenkys
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.

------
jseifer
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.

------
sree_nair
Can get you fired if you have a smart boss.

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

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

