Linus "Linux" Torvalds was interviewed by Slashdot readers with interesting results

Quoting:And when I *do* get involved with the code, it's not because it's 'cool,' it's because it broke, and you'll find me cursing the people who wrote it, and questioning their parentage and that of their pets.

OK, this may be the best Linus quote ever, not because it's the funniest or the most outrageous, but because anyone who had done any serious development work or even systems administration can relate. Being creative when starting with a clean slate or some code/system you know well and getting good results is the fun part of the job. Cleaning up someone else's mess is incredibly difficult by comparison and definitely results in cursing, gnashing of teeth and pulling out hair.

Yeah, I laughed very hard at this too. :o) I *love* Linus in rant mode, he's extremely eloquent and always hits the nail on the head.

> Cleaning up someone else's mess is incredibly difficult by comparison and definitely results in cursing, gnashing of teeth and pulling out hair.

Especially if the documentation is sparse to non-existent.

Quoting:Especially if the documentation is sparse to non-existent.

Is it ever not?

Cleaning up someone else's mess is exactly when you should not be reading documentation, other than specs. No comments, no reviews, no audits, nothing but code. Those other things have no bearing on what the code does, and no bearing on what the code is supposed to do.

Quoting:Is it ever not?

Since I rarely get to fix broken or messy code from really competent people documentation is sometimes poor and mostly it doesn't exist. Much of the hair pulling is in the "Why would someone ever do that?" stage of trying to understand the broken code.

Competent coders, the really good ones, often also produce good documentation. It's a pleasure to follow behind those people. I wish there were more of them.

I never had the pleasure. Which may explain why I ultimately chose a different path.

@gus3: This is one of those fairly rare occasions when I 100% disagree with you. Any insight into why or how the code was written can be very useful in sorting things out.

@caitlyn: Reading that other useless stuff creates a prejudice in your mind of what you think the code is doing, not what it's actually doing.

Most of my programming life was spent taking over someone else's code, I always found that reading the specs was the best. After that one could sit down and work out what the previous programmer had done. Sometimes it was actually what the specs said.