I owe much of my professional success to many excellent teachers, mentors, and colleagues. Early on in my career, I came across a book entitled "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt and David Thomas. I read it through cover to cover, marked it up, and referred back to it frequently when I had some spare time.

"The Pragmatic Programmer: From Journeyman to Master" is a classic software development book that was first published in 1999. This book offers practical advice on how to be a more effective software developer, with a focus on writing code that is maintainable, reusable, and adaptable. The authors cover a wide range of topics, from basic coding practices and design patterns to more advanced concepts like software architecture and project management. The book is written in an engaging, conversational style that makes it easy to read and apply the principles it outlines.

Whether you're just starting in your career or you've been programming for years, "The Pragmatic Programmer" is an essential resource for anyone looking to improve their skills and become a more productive and effective software developer.

Recently I learned that Hunt and Thomas released the 2nd edition of the book, subtitled the "20th Anniversary Edition". They have updated the book to bring it into the modern age of programming (which has evolved a lot over the last twenty years) by including some new information and practices, as well as removing irrelevant examples and paradigms. By and large, though, most of the material in the book remains 'evergreen' advice that developers of all skill levels can continue to benefit and learn from.

I enjoyed the first edition of the book so much that as soon as I learned that the 20th Anniversary Edition was available, I immediately purchased a copy. As I began reading it again, I only got a few chapters in before I decided I needed to start again and start sharing what I learn (and re-learn) from this book. The principles, concepts, tips, and practices from this book are things that all developers should become familiar with and implement into their craft. The advice given is of particular import to those who are just getting started in their careers with software development.

Over the next several weeks as I take a deep dive into this beloved book again, I hope that you will enjoy and implement some of the strategies that the book shares as I review them again.

The Preface

Programming is a craft

I frequently remind my students that programming is something that takes time to get good at. A computer is not simply a machine that you can just read the manual for and immediately know how to do everything it is capable of.

Software development is hard. Harder than anybody who is not familiar with it can understand. When they see an app that has just a few buttons that make a multitude of magical things happen, they assume that the program is simple.

It rarely is.

Do you know what goes into synching information across devices? Do you know where the data goes? Do you know how to secure the data? Do you know where the data is physically being stored? How will where/how the data is stored affect performance? How many platforms can your application run on? How does it look on all kinds of screen sizes?

There are so many contingencies that you have to think about when programming these days. And that is just for starters - that doesn't even address the actual design of a program. You have to build the user interface, write all the code that controls what the buttons do, and protect the users of your applications from doing bad things to their own data. Once you've done that you have to design and implement the actual brains of the application that responds to the input of your users.

My favorite description of programming comes from the preface of the book:  

Programming is a craft. At its simplest, it comes down to getting a computer to do what you want it to do (or what your user wants it to do). As a programmer, you are part listener, part advisor, part interpreter, and part dictator. You try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice. You try to document your work so that others can understand it, and you try to engineer your work so that others can build on it. What’s more, you try to do all this against the relentless ticking of the project clock. You work small miracles every day.

It's a hard job.

I like to tell my students that learning how to program is like learning to play a musical instrument. You can read every book you want about how to play the piano, but until you put your hands on the keys, you will never really learn it. The same goes for programming. You are going to have also get your hands on the keys and write some software. You are going to have to make mistakes. You will need to fix those mistakes. You will need to tackle and solve hard problems. These are the only way to get better at it.

There is no best tool

The internet is both a blessing and a curse. We have an essentially unlimited amount of knowledge about anything you can think of available to us at the touch of a button. Moreover, most of us carry a device with access to that knowledge base with us around in our pockets.

The problem comes when you have everybody simultaneously saying what the "best" way to do something is. What's the best programming language? That's a great way to start a fight in a room full of developers. How about the best operating system? That one might do it even more. You'll have the Windows vs. macOS advocates thrashing each other all day. Then, the Linux crowd will pile on with all the reasons why Linux is the only OS that should exist.

So what actually is the best? That's where learning to become a "Pragmatic Programmer" comes into play. The word Pragmatic comes from the Latin word pragmaticus meaning "skilled in business" and the greek word πραγματικός (pragmatikos) meaning "fit for use". Being a Pragmatic Programmer means that you are always looking for the best tool for the job at hand and basing your decisions on pure logic rather than popular opinion.

Let's take running Linux as your main operating system as an example. There are several YouTube channels about Linux (which is excellent) and about all of its benefits. They tell you how you can make the switch from Windows or macOS, alternative programs you can use, etc. I've tried it. While there are many things I love about Linux and use it on my main computer from time to time (I dual boot it with Windows) it has never become my "main" operating system. Why? Because there are things about it still that just don't quite work for me. I play computer games with my kids and siblings that don't always work under Linux. Sure, I could probably spend hours getting them to work just for the sake of "only using Linux", but I have neither the desire nor the time to devote to an endeavor like that. The "best operating system" for me right now is Windows on my main computer.

At my home, I have a custom-built PC that runs both Windows and Linux. My wife owns a MacBook pro. I have two additional PCs (that I built) that my kids can use for homework and games. I have a Linux server in my home that runs Minecraft worlds and an in-home media streaming service. My work computer is a Macbook Pro. Each system in my home has a different role to play, and each has been purpose-built or specifically selected for those roles. (Though in the case of work, it was "you will use this").

To be a pragmatic programmer, you cannot be wedded to any specific technology, branch, manufacturer, operating system, or whatever. You should pick the best tool for the job in any given situation. Would you pick a hammer to drive screws just because "hammers are the best tools"? Of course not. You shouldn't do this with technology either.

What makes a Pragmatic Programmer?

Programmers are all unique. We all have certain ways we like to do things - such as specific preferences in the way we set up our workstations. Everyone has a favorite code editor. Despite all our differences, however, Hunt and Thomas describe a few characteristics that Pragmatic Programmers all share:

Early Adopter / Fast Adapter

Pragmatic Programmers are early adopters and faster adapters. They like to look at how new technologies can help solve current problems or needs they are working with. They can take something new (like one of those new technologies) and learn and adapt to it quickly.

Pragmatic programmers avoid getting bogged down by tech debt. They do this by adopting new technologies and practices that can improve the programs and services they develop and maintain. While everyone else is trying to keep up, they are forging ahead by looking ahead. Their confidence is born out of experience from trying many different things so they are always aware of what options they have for solving problems.

Inquisitive

Pragmatic Programmers ask questions about everything. Like the previous point, when they see something new, they want to learn how it works. They are always looking for ways something can be improved or simplified.

Critical Thinker

When colleagues say “because that’s the way it’s done” or a vendor promises the solution to all your problems, you smell a challenge.

Pragmatic Programmers are skilled critical thinkers. They never take an explanation for why or how something is done at face value. They will search to find the facts before simply accepting something. If something doesn't work they will find out why and fix things the right way, rather than just masking the problem.

Realistic

Pragmatic Programmers like to understand the underlying nature of technology and things so they can understand their complexities. By doing this, they can give better estimates about how long a feature will take. They can give better explanations about applications or problems they encounter because they understand everything involved with complex systems.

Jack of all Trades

Pragmatic Programmers have a very wide range of skills. Even if they are in a place where their position requires them to be a specialist in one or two areas, they keep up with new developments. They developed a broad range of skills so they are always ready to move on to new areas and challenges as they arise.

By having a broad range of skills, they make themselves more valuable as developers, and to the companies or organizations, they develop for.

Think about your work

I think most programmers are familiar with the feeling of being "in the zone". A state of focus so intense that you feel unstoppable.

The danger of getting into that zone is that you can get tunnel vision about what you are working on. In the worst cases, you can start making changes that don't end up being beneficial to the end product at all. To avoid this, Pragmatic Programmers should always be thinking about their work. After writing a new function, class, or feature, they take a step back and make sure that they are still on the right track.

The reward for thinking about your work is more active involvement with a job that you love. It prevents you from becoming a mindless drone within your place of work. By being invested in your work, you'll find yourself caring more about it.  

Individual pragmatists, Large teams

Most of us either do or will, end up working on teams with other developers. How can one be an individual on a team?

I like the correlation that the authors draw between the craftsman that worked on the cathedrals that were built in the middle ages. Those who build these magnificent structures were all individual craftsmen, working towards the same goal. The same can be true for software development teams. As long as everybody is following the same blueprint, then there is always room for individual craftsmen to contribute.

So it is with software development. Like those who built the cathedrals, one hundred years from now the technology and techniques of software development may seem archaic, but the craftsmanship will still be honored.

It’s a continuous process

Would you expect an apprentice carpenter to become a master in a matter of a few months? Then why do we expect the same of developers? Why do you expect the same of yourself?

Becoming a great software developer is something that takes time. The book refers to a Japanese term called "Kaizen" - making continuous small improvements. Every day, find something to work on to add to your skill set. It doesn't have to be something big. Try a new programming language for a day. Build a small project just for fun.

Over time, you will find yourself getting better and better. You just have to give yourself the time to learn and make mistakes. I have to remind myself to do this frequently as well. There is so much to learn, and the only way to learn it is in little bits at a time.