For the duration of about four months, I was part of a study group centered around the book “The Pragmatic Programmer”, by David Thomas and Andrew Hunt. The group had weekly remote meetings to discuss the section planned for that week. In these meetings, there were usually about five people and we discussed topic by topic. After several weeks, we finished the book.

Before the study group started, this book had been recommended to me by a couple of people I know. However, I had my doubts if being a “pragmatic” programmer was a good thing, since I disagree with pragmatism in philosophy. So my first question going into this book was on the meaning of “pragmatic”. And the authors address this question right on the preface. Here’s a quote that shows how the authors view pragmatism in this context:

“There are no easy answers. There is no best solution, be it a tool, a language, or an operating system. There can only be systems that are more appropriate in a particular set of circumstances.

This is where pragmatism comes in. You shouldn’t be wedded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations.”

I agree that you shouldn’t just stick to a particular technology and apply it to every problem you encounter. In fact, I agree with most of this quote. I just don’t agree with the word “pragmatism” being used here. I can see some resemblance to the pragmatists in ethics, but I don’t think it is a good comparison. According to pragmatists, you shouldn’t rely on absolute principles or standards or values, there is no such thing as objective reality or permanent truth, truth is “what works”. However, to decide if something “works” or not, you need a way to judge, so you need a set of values, and pragmatists are against a “rigid” set of values. For example, is sharing your knowledge with other people in your company something that works? That depends on your values. If you value your company being able to produce more and better for customers, then yes. If you value being the only person that can do this work so you keep your job, then no. Pragmatism doesn’t offer any guidance on what your values should be. Looking at it this way,  pragmatic ethics is basically contentless and offers no guidance whatsoever. The first numbered tip of the book already goes against pragmatism: “Care about your craft”. This is explicitly naming that you should value your craft.

So, for the authors’ definition of pragmatism to be correct, relying on principles in ethics should be equivalent to relying on a particular technology in software development. But a principle and a particular technology are completely different. A principle offers guidance, not a solution, and a particular technology offers a solution or part of a solution, not guidance. And, after reading the book, I could clearly see the authors offer principles and care a lot about following them. Yes, these principles were derived from their experiences, but a pragmatic approach would be to not generalize and always think that each context is completely different and there would be no use for generalized principles.

All that is to say that, since I see the word pragmatism as something useless that offers no guidance and I disagree with what the authors call pragmatism, it means that I think the authors are able to provide me with good guidance in this book. In other words, I am glad that I disagree with them on that term, otherwise I would not find this book helpful. Now I can talk about what I actually like about it, which is everything else.

I would not classify “The Pragmatic Programmer” as a technical book. Sure, there are technical subjects and code examples, but it is much more than that. It is more about a work philosophy for developers. This is clear right on the preface, where we find the first two numbered tips: “Care about your craft” and “Think! About your work”. This is philosophy, and that’s a good thing. Philosophy is necessary for every human being. And these two tips are very integrated. After all, if you care about your craft, you will think about it constantly. And if you are thinking about your work constantly, it means you care about it. This integration is very prevalent throughout the book. All the topics relate to one another in some way. And that’s how a philosophy should be.

The authors show that independence and individuality are very valuable. You can act on your own. If you are unhappy where you are, you have the ability to change that. You will be able to more easily change your situation if you continuously improve yourself. And programmers can work on projects that can change other people’s lives or even change the world. Developers can be a catalyst for change. If you see yourself and your work in this way, you will realize that you have great independence and great power. “But with great power, comes great responsibility”. Other people need to trust you to give you this kind of responsibility, and your team also needs to trust you. So being honest, owning your mistakes and taking responsibility are essential. Don’t make excuses. And apart from trusting that you are responsible, people need to trust that you will deliver something with quality and that delights them. And since you care about your craft, you will want to be proud of your work and, doing so, you will make your name be a certification of quality.

Those were the central points of the book in my view, because everything else is aimed at helping the readers to be more independent, trust-worthy, proud of what they are doing and continue doing that. And there are a lot of helpful tips and guidance to achieve that and I can’t possibly name them all in this post. But I can list a few in a very interrelated way:

Work with incremental steps. Deliver one small thing that works end-to-end to get feedback from your users quickly and to make sure you are “hitting the target” (this is called the “tracer bullet” approach). This way, your whole project is a process of gathering requirements. And to be able to change what was delivered after getting the feedback, the design should be Easy To Change (ETC principle). If there is a crisis and you need to change something in an emergency, you still shouldn’t break the ETC principle or other principles of good design. Solving a crisis does not mean you should easily tolerate collateral damages, otherwise people will stop caring about having good design in the project, and you will not be able to easily change it in response to feedback. Another factor that helps you respond to feedback is the ability to deploy your changes quickly to the users, which makes automation and continuous delivery important.

There were also some topics that were brought up during the wrap-up meeting of the study group. One of them was the idea of writing daybooks. Everyday, write about what you are working on, decisions you’ve made, ideas you can’t explore at that moment, among other things. By doing this, you can remember some important stuff in the future, and also feel some nostalgia. Another topic was about communication. You should communicate in a way other people can understand the message. That involves saying the same thing in different ways depending on your audience. If it is in written form, make it well formatted, well written, without spelling mistakes. Be a good listener. And always answer, even if it is something like “I’ll get back to you”.

Again, there are a lot more useful tips in this book. I would not be able to explain them all in the way the authors did, mainly because I don’t have as much experience as they do. So, my suggestion is: read “The Pragmatic Programmer” by David Thomas and Andrew Hunt to become a better problem solver, programmer, developer, or whatever you want to call this craft. These two authors have had more than twenty years of experience and were among the original authors of The Agile Manifesto. They’ve written the conclusions and views they’ve formed with all this experience in a very accessible language. So read this book to take a very time-saving shortcut.