Pragmatic Programmer - a must read for every programmer
Some time ago I published a post about the books I think every Ruby/Rails developer should read. This time I’ll briefly describe another one - the classic Pragmatic Programmer from Andy Hunt and Dave Thomas. It doesn’t fit the post I’ve mentioned above because it’s a book I think every programmer should read. Not only the web developers, or the Ruby/Rails ones.
Pragmatic Programmer is an essential book for every single programmer, regardless of the language one works. It doesn’t show you the code examples you can apply in your project. Instead of that, it shows you the way which a professional programmer should follow. It was published in the last millennium, and it’s still worth reading today. It seems to be timeless, at least for now :)
From the book
You can find a lot of reviews of Pragmatic Programmer online so posting another one actually doesn’t make sense. Instead of that let me just copy and paste some of the quotes/anecdotes. There’s much more of them, but it’s a blog post, not an essay so I’ll just paste a few to demonstrate what you’re missing if you haven’t read this book yet :-)
Code duplication and strange solutions
It’s not a question of whether you’ll remember, it’s a question of when you’ll forget.
The greatest of all weaknesses is the fear of appearing weak
Provide options, not excuses.
It does not really matter whether the bug is your fault or someone else’s. It’s now your problem.
Code reversibility and alternatives research
This one points out that there’s always another way to implement something and/or another vendor for an external service.
Nothing is more dangerous than an idea if it’s the only one you have.
Requirements, understanding, and bad assumptions
If one person misunderstands, then it’s possible many people do.
The one below is actually a well known one, but it’s just great!
Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.
This one is called a Levy’s Eighth law.
No amount of genius can overcome a preoccupation with detail.
Pragmatic programmers trust no one, including themselves.
Don't use wizard code you don't understand.
Developers who don’t actively think about their code are programming by coincidence - the code might work, but there’s no particular reason why.
Test your software, or your users will.
Once a human tester finds a bug it should be the last time a human tester finds that bug. If a bug slips through the net of existing tests, you need to add a new test to trap it next time.
As soon as any production code exists, it needs to be tested.
This is a quote from Robert Frost, written in context of the Law of Demeter :-)
Good fences make good neighbors.
That one is a Chinese proverb, telling you that you can’t remember everything. The more you write, the less you’ll forget.
The palest ink is better than the best memory.
Broken windows story
One of the stories tells us that when a building has a broken window and nobody fix it within a certain period of time, the condition of the building gets worse and worse. Next broken windows start to appear, then graffiti, or two, and the building finally becomes a ruin, because nobody took care of it. The same is with your code and it’s quite coupled with The Scout Rule - if you see something is wrong in your code, try to fix that. Otherwise, your project will become a ruin.
Don’t boil yourself!
Another anecdote was about boiled frogs. When you put a frog into hot water you can watch an immediate escape. The water is too hot and the frog is jumping out to survive. But if you put the frog into cold water and start warming it up, the frog will not notice changing temperature and finally end up boiled. Again - you should react as soon as possible if you see problems with your code if you don’t want to get boiled!
Sabotage is not so bad
Everybody know that testing the code is important, but one nice idea described in this book was something called sabotage testing. Its purpose is to test your tests :) The idea is to invite someone from outside the project, let him/her change one line somewhere in the code and check if your tests catch it.
That’s it, there’s nothing to sum up. Just grab this book if you haven’t done that yet and read it from the beginning to the end! If you find something interesting and I’m missing it here - Let’s talk about it! :)