Studying (not just reading) good code is as essential. By just writing your own code, you will stuck with it, without ever improving.

You have to look at rails (or turbogears which i prefer) or you will stick with Struts and Co.

I thought you were going to talk about Grand Theft Auto. :)

IMHO, you not only have to write code, and non-trivial code at that, you have to be prepared to look at code you've written in the past and admit that it sucks. Once you can do that objectively then you can then knuckle down and learn some more so that in the future you write "better" code.Rinse, repeat.

To get to the point where you know that your code sucks you have to read a lot of the "right kind" of code and a lot of the "right kind" of books and then be brutally honest with yourself. Finding the "right kind" of reading material is often the hard part. Books like Code Complete are a good start, finding the "right kind" of code is often much harder but you can also learn from the "wrong kind" of code. Don't just hate those crappy code-bases that you're forced to work on, learn from them. Work out why they're "bad". Write about it, perhaps, if you can, but certainly think about it.

Once you've been through the loop of writing code and being self critical it's time to let others pull you apart. Taking part in an open source project or writing and publishing articles (on the web or in print) about code that you've written is a good way to do this. Write some code, polish it until you think it's good enough and then let others see it so they can tell you that it isn't. Once again, learn from the feedback, adjust and write better code.

Then you just have to keep doing that forever. IMHO, as soon as you stop taking feedback (either from your newly educated self or from others) then it's game over, time to find a new career...

I think a healthier attitude than Len's is something Ron Jeffries says from time to time, regarding old code. Paraphrasing; sorry, it's a tough one to google: The problems we see in yesterday's code are not bad news about where we were then; they're good news about where we are now. That is to say, if we're going about this whole thing well, we should be learning all the time, and the things we learn give us an ever-improving perspective on the code we (and others) write. If the code is no good from today's perspective, or with today's requirements: make it good; now we have the perspective to do so.

I don't want to disagree that it's important to be able to acknowledge that my own code then - and sometimes now - sucks; just to suggest it's more productive to focus on the positive.

I would say that reading is just as important as writing. You can write all day and all night and then some, but if you aren't doing a fair amount of reading, then you won't be getting better so much as writing a lot. It's hard to improve in a vacuum.

Programming is different - it has to compile, it has to run, it has to _do something_, so learning on your own is a much more feasible endeavour (although if you aren't reading code, you're probably reading books or websites about programming)

When it comes down to it, I think the goal you should shoot for is to always have learned enough on any given project that when it's over you can already think of a better way to approach at least one aspect of it (if not the entire architecture!)

Actually, I have to chime in here. The way to become a great writer is to practice writing AND to read, all the time. If you read often, your vocabulary is enriched (though you may not always know how to pronounce everything correctly). Couple that with reading ABOUT writing and you're getting to be a better writer.

I believe that the same thing happens with writing software. You write code, you read code. You work on code that's better than your code and you read code all the time, while doing that you learn methods for solving problems etc. Couple that with reading ABOUT programming and you're going to write better software.

Or something.

Insert appropriate "My code goes to 11" joke here.

The whole idea of the rock star programmer is a weird one- when did you last hear some beautifully composed C or a rebellious three minute Ruby classic on the radio?

It can be done though, I reckon; two members of my band (link under my name) are programmers by trade. We're not rock stars yet, admittedly (and as bassist I'm the band member least likely to get noticed in the street even if the album does start selling by the million) but that seems like the most convincing way to combine the two roles to me.

couple things here, yes you can read other source code, but!
- don't copy and paste that to your projects, yes it's so much faster, bla bla... but you didn't benefit from it, other than the fact that you got that particular problem in that moment, done, if you actually write it yourself you learn more (of course this doesn't always apply, there are times when you use full libraries written by someone else), I'm talking about snippets of code

- anytime you see a better technique than the one you use, take it!, this is perhaps the biggest problem with programmers, not willing to take other techniques, standards, etc

I know that when I've read good code and recognized it as such, my own programming style picked it up fairly quickly. While I've been programming for 10 or 15 years and been decently self-critical, sometimes it just takes another person's style or perspective to notice how my own routine can improve (especially with things like commenting).

To give a clear example, the art of commenting is something that's so hard to learn how to do right until you read someone else's code that's well-commented (and realize what you appreciate about it). In that sense, I know I've seen the value of reading other people's code, but I still partly agree with Jeff in that the value is only realized when one writes one's own code.

I totally agree. It's like trying to learn a language by reading textbooks. Reading can help, but there's no substitute for doing.

I'm not proposing that we all burrow underground and code only using our own ideas, totally disconnected from the internet. Is that even possible any more?

I maintain that writing code is the real "one tip to bind them all." Keep reading, of course, but most importantly, *write as much as possible*. I think a ratio of 20% reading/learning and 80% writing is close to optimal.

Also, as a counterpoint in favor of reading other people's code, I really liked
Marc-André Cournoyer's Ruby example:

http://macournoyer.blogspot.com/2006/03/rock-star-programming-my-two-cents.html#comments

You definitely want a mixture of reading and doing, but with a heavy, HEAVY emphasis on the "doing" part.

I have as a goal improving my coding skills to the point where I stay out of TheDailyWTF.

Carl

I agree with you. My attitude (at least to improving my coding) isn't that unhealthy, really ;) The point I was trying to make is that unless you can accept that your code can be improved upon then you're unlikely to push yourself to improve it. I don't find it negative to get criticism of the code I make public I relish it as it means I can think about the issue and, perhaps, learn and grow.

I have a simpler one, learn from other people's mistakes.

However, we don't always get the chance to look at other people's code.

Which is why one of my ideas, is to create a global code repository of applications.

1. To help review each other's code
2. To improve the quality of code globally
3. To help improve reusability and quality control
4. To offer code testing

I mean i want to help other people but i also want to be helped as well..

> Rock stars get sex, drugs, parties, limousines, > fame, glory, dates with supermodels, and
> Rolling Stone covers. Good programmers
> get . . . uh . . . fewer compiler errors.

Ummm, I don't know about you guys, but, with the exception of the rolling stone cover, I did get all of the above as a rockstar programmer.

But I found that trying to attend to the enormously nitpicky needs of supermodels actually increased the number of compiler errors I ran into (as did all that blow). So I gave up on that lifestyle.

Jeff Atwood: you need a slap, that link is surely an example of "how to be a rock star programmer in your own mind that no-one else should want to copy". The example shows a simple piece of code that is refactored down to a single line using Ruby.

Now I know Ruby is flavour-of-the-month and so such things are cool, but imagine if the author had written his string comparison and assignment using only a single line of source using C.

Maybe that's the point though, rock stars are mostly known for their excesses and arrogance after all :-)

I think you definitely become a better writer by reading a lot of books. Picture a chef who's never been to a restaurant. Think he's any good?

What a fantastic insight into coders. What other group of people would take the term "rockstar X" and apply so literally and unquestioningly? I'm not a rockstar brick-layer because I'm not snorting cocaine from the thighs of underage prostitutes every night? Therefore there are no rockstar brick-layers. Absolutely priceless; it's just a metaphorical adjective you nerds!

(Nerd, the 'other' n-word. Teehee.)

The one I found most insane was #9. Especially considering #6.

So looking through a book written 3 years ago by someone who can't even see your code is good practice, but asking for help from someone who can look at your code, see the error you're making, AND THEN POINT TO THE ERROR YOU'RE ABOUT TO MAKE, is wrong. Someone whose advice is specific rather than general.

Somewhere, right now, some poor CS student is refusing to ask his tutor something he could answer with a word, because of MGeek Jaggnerd there.