The Pragmatic Programmer – Review

So I have finally finished The Pragmatic Programmer from cover to cover, including Foreword, solving the given problems and rethinking what every tip could do for me and how I could improve the way I work.

I’ve mentioned having this book finally ticked as “done” to my friend and great coder Martynas, he (quite skeptically) said:

All of it should have been quite obvious, wasn’t it?

Like an example he mentioned the Tip No. 4 “Don’t Live with Broken Windows”. Well yes, isn’t it quite obvious? I’ve even wrote it myself in Conditions Suck:

The thing is, if it is done wrong, most probably, while implementing some small change, it will force you to keep the existing bad style. Eventually, if code smells, it will start to suffocate you as the stench grows.

Or “Always Use Source Control”. I mean, who does not use source control these days for everything they write?

So depending of how long you have been in the industry, you might find that you already are using all the techniques described in this book. They aren’t magical, they are just some clever things that you’d eventually find out yourself as you work. Just like Design Patterns or absolutely everything else.

Furthermore, I think that at least half of them are put in our heads almost as soon as we start writing code. For example tips about testing, I remember coding in first courses in university when I was implementing such things as Dijkstra algorithm, Stack, List and other stuff. I haven’t heard about Unit Testing at that time, however instead of using debugger, I wrapped my functions in little tests to see if they really do what I want them to, which I’m sure most of us did. And now testing is becoming a basic routine for majority of coders.

The most obvious Tip on the book is “Don’t Repeat Yourself”. I’m sure we all heard it the day we’ve learned about functions. The book takes it much more serious though — it is the main tip that almost all the book is based upon (for example in “Code Generators”). But still it is the same principle and when you’ll find yourself repeating, you will think how to avoid it and finally get rid of it, right? Well, not always, at least for me. As written in chapter “… Boiled Frogs”, you could easily forget something, then suddenly it goes out of hand and next thing you know — you are boiled. Maybe you’re repeating some simple actions every week that take 15 minutes or so and don’t even think about it as a big deal, but after reading chapter on automation, in 30 minutes you will write a script that does it for you. It might save you from some trouble that would happen if you would forget something. Or any other tip. It might just hit you in the head.

And that is the main strength of this book, it MAKES you think. Yes, you might know all the principles in the book, work by them, but isn’t there a place for improvement? The great analogies in The Pragmatic Programmer might just give you a hint on what could be done better. Isn’t to buy list just the reminder not to forget milk? But you still read them? Well, The Pragmatic Programmer might be just that, a great reminder, so you won’t forget.

For anyone with less experience, the recommendation would be a no brainer — this absolutely is a must-read.

While I work with Legacy Code, the biggest issue for me was that some of the tips are really useful for new project but might not really work well existing code base. And none that would aim straight for legacy code. That’s why now I’ve picked “Working Efficiently with Legacy Code” by Michael C. Feathers.

Oh and favorite tip? That would be No. 44:

Don’t Program by Coincidence