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
13 comments:
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.)
You're absolutely right, it does apply to martial arts, too. That reminds me of a story, which I will have to post soon.
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!
http://www.codinghorror.com/blog/archives/000552.html
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.
Amen broda! But how do we tell good code from bad code?
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.
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."
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...
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.
"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").
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.
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.
Popular code is often good code, so check things like DotNetNuke, etc.
Post a Comment