Wednesday, March 22, 2006

The One Tip That Rules Them All

An article called My Top Ten Tips on how to become a Rock Star Programmer has been circulating on the net. It is probably well-intentioned, but I'm afraid it misses the mark.

How to be a Rock Star Babysitter

Let's start with the title. There is no such thing as a "Rock Star Programmer," so if you want to become one, you already have problems that reading a blog post can't fix. Rock stars get sex, drugs, parties, limousines, fame, glory, dates with supermodels, and Rolling Stone covers. Good programmers get . . . uh . . . fewer compiler errors. Or fewer runtime errors, depending on which language you're using. So let's not pretend that "Rock Star Programmer" makes any more sense than "lighter-than-air paperweight" or "Rock Star Babysitter."

Tips 1, 2, and 3 advise using a fast machine, a big monitor, and all the features of your IDE. This is like telling people to become better guitar players by buying a more expensive amp and turning the volume up to 11.

Tip 4 says not to learn APIs too well because they might change. This is like telling a musician not to learn a scale "too well" because the next song might be in a different key.

Tip 7 says to "go back and enhance your old code" because "you learn oodles of things reading your own crap, which old code always is." Sorry, but you don't learn how to write good code from reading your own bad code, you only learn why bad code is so aggravating.

Tip 8 says to eat your own dog food, and write something using your own API. This is decent advice, but just like tip 7, you won't learn how to write good code by using your own bad code, you will only learn why your own bad code is just as hard to use as it is to maintain.

This list overlooks the one obvious tip, the one tip that rules them all and in the darkness binds them.

The One Tip That Rules Them All

You don't learn about good code by studying bad code. You learn about good code by studying good code.

  • Reading bad code won't teach you about good code
  • Writing bad code won't teach you about good code
  • Using bad code won't teach you about good code
  • Compiling bad code faster with a faster machine won't teach you about good code
  • Seeing more bad code on the screen at once with a bigger monitor won't teach you about good code
  • Writing bad code faster with IDE shortcuts won't teach you about good code
  • Performance testing bad code won't teach you about good code
The best way to improve is to study code that is better than your own. Read good code written by experts, in a variety of programming languages. Study it until you understand how it works and what makes it good. That's it. That's the one tip. Oh yeah, and also take the money you would have spent on a faster machine and a bigger monitor and send it to me.


LeesMyth said...

Hmmm. Maybe the article is not so well-intentioned. There's an 11th tip, not listed in the article: "Give bad advice to your fellow programmers so they will make you look really good by comparison."

Your one tip that rules them all (great conversion, btw) applies to many things in life. I got pretty good at karate for a while by constantly sparring with brown belts -- about 4 levels above me. (My primary sparring victim, er, partner was very patient with me, but it must have been aggravating to her not to get to spar much with the black belts, from whom she could learn.)

Tom said...

You're absolutely right, it does apply to martial arts, too. That reminds me of a story, which I will have to post soon.

moe said...


Jeff Atwood said...

Reading is too passive. You don't magically become a better writer by reading a bunch of books, no matter how fantastically amazing the authors were. You become a better writer by WRITING!

beza1e1 said...

I disagree. The best method to learn is to do it yourself and learn from your mistakes.

Of course you need to study the good code and understand it, but then you have to read your own bad code and find out why it sucks.

You don't learn math by reading the solutions of your teacher. You don't learn to code by reading outstanding code.

Anonymous said...

Amen broda! But how do we tell good code from bad code?

MAC said...

I totally agree with you. I've blogged a bit more about the Don't learn API @

Tom said...

Thanks, all, for the comments. Of course you do have to write code as well, I assumed that was a given. But learning only from your own mistakes is just "trial and error" and it is a slow way to learn, though it may work eventually. Reading other people's code that is better than my own is the quickest way for me to see new approaches that I never would have thought of by myself. Or maybe I would have eventually thought of them after lots of trial and error, but I don't want to wait that long.

Jens said...

I guess the truth lies somewhere inbetween. You certainly can learn a lot from good code - but only if you are experienced enough to recognize and appreciate it. If you have never experienced the trouble with copy-and-paste in a bigger project, you will not appreciate the DRY principle and the benefits of factoring that code out. If you never had to go back to a 4000 line java-class to add a new feature, you will not understand why it is good to keep your classes small. The list goes on and on...

I guess my point is that I believe the rule should be something like "Make your own mistakes, but only ONCE. Learn from better code how to avoid them in the future."

Anonymous said...

Reading other people's code is cool, though its not always easy to know whose code is "good" code. Is the sendmail MTA code "good"? It's some of the most widely deployed code in the world, right? On the other hand, your buddy down the hall may have a beautiful, elegant class library for performing operations in the foo and bar domains, but they've never seen the light of day. They sure are pretty though.

Frankly, I found that having experience, then studying books such as Code Complete, effective c++, Advanced c++, etc., and working with a great team of other c++ guys, was probably the most effective thing for me. A lot of these "advanced" books really only start to make sense after you've screwed up a few class libraries and driven a few frameworks into the ground...

Anonymous said...

You have some valid points, but tips 1, 2, and 3 are more akin to replacing your cheap Walmart guitar and amp that won't stay tuned and sound like crap with a Les Paul and a Marshall stack.

Anonymous said...

"Sorry, but you don't learn how to write good code from reading your own bad code, you only learn why bad code is so aggravating."

This is dubious. People can and do learn from their mistakes (or other people's mistakes). I reckon a good 75% of my coding improvement is due to bitching about code -- "why did the farking idiot do it that way, when it would have been far more readable/maintainable/extensible if it were done this other way?"

(And a good two-thirds of the time, I'd finish the rant with "oh, wait, this is the code I wrote a year ago").

Tom said...

People do learn from their mistakes, you're right. My point is that although bad code might inspire you to write better code, it does not show you how to write better code. You can either figure out how to write better code by trial and error and "reinventing the wheel" (which is, in my opinion, a slow way to learn something), or you can take the more direct route of studying good code.

Robby Slaughter said...

No, dude. Reading code helps; even good code. But it's not the best tip ever.

The number one tip is TAKE YOUR TIME. Be thorough. Exhaust every possibility. Obsess over data structures. Question and recollect the requirements. Basically programming problems I have ever seen stem from rushing.

A close second, however, is don't be too clever. In coding, "cute" is the enemy of good.

Anonymous said...

When discussing whether one can improve one's code by looking at better code, it's worth having a look at Paul Graham's essay Beating the Averages, especially the part about "The Blub Paradox," a parable about the fictional Blub programming language. Its message is that it's difficult to adopt something that's better than what you know because you can't even perceive it as being better. The story goes: If you could see as better, you'd understand why it's better and be using the concepts. To be fair, it's rare that somebody else's code is completely opaque, but learning something from that code requires a particular selflessness, one that's hard for most to achieve. Not out of the question, but it takes a real committment.

I'd add that it's especially true when the other code is significantly better than yours; you'd probably "get" the improvements very easily if they were only small improvements, but code that's WAY better is gonna be, like, in a language you don't understand.

None of this negates the essential point that you can learn from better code, but it is a difficult approach.

InfoBlips said...

Popular code is often good code, so check things like DotNetNuke, etc.

rodrigogard said...
This comment has been removed by a blog administrator.