The pragmatic programmer by Andrew Hunt – Book Review

” The pragmatic programmer ” was always on top of the list when I searched the required readings for programmers. And when I check on its reviews much people say ” I should have read this a long time ago, it would saved me so much time and effort “. So I decided to give it a read, and it was worth it. I would leave in this article the Pragmatic Programmer ‘s checklists and tips. As well as a quick pros-and-cons scan and obviously my recommandations for people who want to read it.

The Pragmatic Programmer – Overview

This book is build around 70 tips. Some of these tips are general principles and some are ways of thinking. Some are technical and some cover soft skills. There are lots of stories and quotes. I don’t want to spoil any of them by giving them away, but I do have a few favorites that I’am listing in the next section. For this section, I am listing what you might like about the book, and what might seem not very compelling to you.

+ First thing you would love about the book is that it comes with a quick reference card containing a summary of these 70 tips. I found this “very pragmatic” !

+ Actually the whole book is “very pragmatic”! reading it you will have years of experience packed in a small package in your hands. Most of its information is practical real world truth and not just theoretical advices.

+ Even though it has alot of Java, C and C++, this book doesn’t target a specific platform or language. It’s a set of technology independent tips that can be applied virtually anywhere. The authors made the book so code autonomous, yet they allowed real code to be showcased to make the points necessary.

± Some of the references  and tips are no longer valid as the book was publised in 1999. You would only get this when you read it.

± If you are already familiar with many of the software craftsmanship or general agile principles, much of this book will echo what you already know.

± If not, with all the suggestions for improvement, it’s possible to get a bit overwhelmed. Just realize that mastery takes time and don’t expect to do it all at once.

Summary

1- A Pragmatic Philosophy

This first chapter discusses the core attitudes and behaviors of a pragmatic programmer – like being responsible, dealing with change, the importance of communication, and increasing your knowledge and experience. It comes with so much intresting sections like “Software entropy”, “Your knowledge portfolio”and “Communicate”.

While software development is immune from almost all physical laws, entropy hits us hard. Entropy is a term from physics that refers to the amount of “disorder” in a system… When disorder increases in software, programmers call it “software rot.”
There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project. Even if you are a team of one, your project’s psychology can be a very delicate thing.

2- A pragmatic approach

This chapter reveals useful but rarely documented tips and processes for things like decision making, creating prototypes, debugging, producing estimates, and domain languages. It containes sections like “Prototypes and post-it notes”, “Reversibility” and “Estimate”.

There is always more than one way to implement something, and there is usually more than one vendor available to provide a third-party product. If you go into a project hampered by the myopic notion that there is only one way to do it, you may be in for an unpleasant surprise.

3- The basic tools

This chapter identifies the standard tools every programmer , pragmatic or not, who wants to excel at their craft needs to master. This includes scripting languages, text editors (and the need to be very proficient with them), revision control systems, and command shells. Sections in this chapter include “The power of plain text” and “Source code control”.

But if you do all your work using GUIs, you are missing out on the full capabilities of your environment. You won’t be able to automate common tasks, or use the full power of the tools available to you. And you won’t be able to combine your tools to create customized macro tools. A benefit of GUIs is WYSIWYG—what you see is what you get. The disadvantage is WYSIAYG—what you see is all you get.

4- Pragmatic Paranoia

This chapter  acknowledges the painful truth that no software is perfect and provides some ideas on how to find and fix errors as early as possible and minimize the effect of errors that make it into production code. Sections contain “How to balance resources”, “When to use exceptions” and “Assertive Programming”.

If It Can’t Happen, Use Assertions to Ensure That It Won’t . Whenever you find yourself thinking “but of course that could never happen,” add code to check it… All errors give you information. You could convince yourself that the error can’t happen, and choose to ignore it. Instead, Pragmatic Programmers tell themselves that if there is an error, something very, very bad has happened.

5- Bend or Break

This chapter covers some techniques for writing code that is easily maintainable and modifiable. Sections include “Decoupling and the Law of Demeter”, “Metaprogramming” and “Temporal coupling”.

There are two aspects of time that are important to us: concurrency (things happening at the same time) and ordering (the relative positions of things in time).We need to allow for concurrency and to think about decoupling any time or order dependencies. In doing so, we can gain flexibility and reduce any time-based dependencies in many areas of development: workflow analysis, architecture, design, and
deployment.

6- While you are coding

This chapter rails against the notion that coding should be approached as a mechanical process that converts a detailed design into source code. The authors suggest that mindlessly translating a design into code is a primary factor in creating poorly written, and sometimes actually wrong, software and that programmers must constantly be thinking about what they are writing and how it effects the rest of the system. Sections contain “Programming by coincidence”, “Refactoring” and “Algorithm Speed”.

Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn’t know why. Fred may well spend a significant amount of time chasing this piece of code around without ever being able to fix it. No matter what he does, it just doesn’t ever seem to work right. Fred doesn’t know why the code is failing because he didn’t know why it worked in the first place.

7- Before the project

This chapter focuses our attention on some key things that need to be addressed at the very beginning of a project like eliciting and documenting requirements, dealing with constraints, producing specifications, and development methodologies. Sections include “Not until you’re ready”, “The specification trap” and “The requirements Pit”.

Great performers share a trait: they know when to start and when to wait. The diver stands on the high-board, waiting for the perfect moment to jump. The conductor stands before the orchestra, arms raised, until she senses that the moment is right to start the piece. You are a great performer. You too need to listen to the voice that whispers “wait.” If you sit down to start typing and there’s some nagging doubt in your mind, heed it.

8- Pragmatic projects

This last chapter moves from the realm of pragmatic individuals to pragmatic teams and discusses several topics that can lead to the ultimate success or failure of a project. Its sections include “Pragmatic teams”, “Great expectations” and “Pride and prejudice”.

Users initially come to you with some vision of what they want. It may be incomplete, inconsistent, or technically impossible, but it is theirs, and, like the child at Christmas, they have some emotion invested in it. You cannot just ignore it.
As your understanding of their needs develops, you’ll find areas where their expectations cannot be met, or where their expectations are perhaps too conservative. Part of your role is to communicate this. Work with your users so that their understanding of what you’ll be delivering is accurate.

Recommandations

If you are a beginner programmer looking to become a great programmer, and you want to approach the topic from an attitudinal and discipline approach, I think ” The pragmatic programmer ” is very relevant. If you want to approach programming from a nuts and bolts perspective, I’d suggest getting knee deep into a language first and then come back to this. Also, this book is targeted to programmers who love what they do and want to be better at it. In fact, the first tip in the book is “Care about your craft”. This means if you don’t enjoy developing software, you shouldn’t be doing it. So you shouldn’t be reading this book!
Overall, I am really happy I read the book and I would highly recommend it to other programmers. It is worth of its place on almost all the must-read list for programmers I found on the internet. I could already feel some of its advice reshaping how I look at code!