For the last couple of weeks I’ve been slowly reading a book I recently got - “The Pragmatic Programmer, The: From Journeyman to Master” (Authors’ website).

Andrew Hunt and David Thomas cover a lot of topics in this book, such as DRY principle (Do not Repeat Yourself), orthogonality, project management and many more. Challenges and exercises at the end of pretty much every single topic gets you thinking about your present code.

Software Entropy

This particular topic was a bit shocking. Software entropy is basically disorder in software, bad code, “rotten software” as they refer to it. As an example they talked about a research in why some buildings get damaged “beyond the owner’s desire to fix it”, while others stay pristine and clean. **“A broken window.” **“One broken window, left unrepaired for any substantial length of time, instills in theinhabitants of the building a sense of abandonment—a sense that the powers that be don’tcare about the building. So another window gets broken. People start littering. Graffitiappears. Serious structural damage begins.”

When you think about it, they have a really good point. I can tell from my personal experience, that if you leave “broken windows” in software - bad design, poor code, more will appear in near future if they are not repaired.

Programming by coincidence

Many programmers have this problem, I sometimes find myself doing just that - programming by coincidence. Authors emphasize that you must know or must find out **WHY **it works in the first place, because when problems occur (and they will), you will not be able to deal with them. Not only that, but in my opinion it will make it harder for others to work with your code.

Other topics

Other topics include using Version Control Systems, importance of orthogonality and decoupling, plain text, code generators, project management, testing (important one!), code refactoring, automation, knowing your tools (!!!).

Anything wrong?

Only one thing that bothered me just a bit was that examples were only given in Java or C/C++ languages. But at the same time I understand that the example code is not that important, the point was to get the reader into a right mindset, pass a correct message. One way or another the code was not that hard to understand, since pretty much every single programming language is similar in some ways. So it’s not really a bad thing in my opinion.

Conclusion

This book is by far one of the best books I’ve read on programming. In fact I found some similarities (in described practices) to an e-book “The best of edw519“ by a Hacker news Top contributor Ed Weissman. This should definitely be on every programmer’s to-read list. “The Pragmatic Programmer” really changed my mindset.

“The Pragmatic Programmer” on The Pragmatic Bookshelf

“The Pragmatic Programmer” on Amazon

EDIT: If you want to find out more about the content, “The Pragmatic Programmer Quick Reference Guide” on Jeff Atwood’s website.