The Pragmatic Programmer

This is a book by Andy Hunt and Dave Thomas about programming, but not in any particular language. It’s about all the other things that go along with programming, beyond just writing code. It’s a perfect book for beginners or people who don’t have a lot of experience working on a huge code base. You can learn pretty quickly how to write code that works, but writing code that is easy to read and maintain is whole other process. This book is a great place to start if you’re writing code that runs but is still sort of a mess. I feel like a lot of the advice would be common sense to someone with 5+ years of programming experience, but for beginners with a basic understanding of software development and coding this book is a perfect place to start learning how to think about the big picture.

It’s a Great Time to be a Developer

One thing I kept thinking as I read this book was how much new developers take for granted. Learning web development starting with Rails 4.x is a treat. Things like modular code, composition as a design pattern, and the MVC framework are a given. For developers who learn Rails first, this is just how things are. These patterns seem to be getting more popular, but I got the sense from the book that back when it was written (1999), this was not at all the case. This book gave me a glimpse into the world of software development before those things were standard practices and really makes me realize just how much groundwork has been done already.

There were also two huge sections and countless references to the importance of testing. This is something I also find relatively common among other Rails developers. Of course there are lots of untested Rails apps out there, but almost all of the medium to large sized Rails projects I’ve seen have pretty good test coverage, often up to 100%.

Don’t Try to Predict the Future

A message that always comes up in books like these is don’t try to predict the future. I guess a lot of software developers have wasted a lot of time and money building software that nobody uses. The authors of this book use analogies to explain why you shouldn’t just guess what your app should be like. The one I like the most is their comparison of developing new features to using tracer bullets.

They liken building software to aiming at a target. When you first set out to accomplish your mission you have an idea of what your target is; what it should look like. The thing is, you probably don’t know where exactly that target is. In combat, soldiers use tracer bullets that light up when they’re fired along with their regular ammunition so they can see what is going on close to the target. The authors recommend using “tracer-bullets” in your code: try something that solves your problem quickly, visibly, and repeatably, but leaves a trail. “Tracer bullets” also provide instant feedback. They don’t always hit the intended target, but they at least make it clear what target you are hitting. Rather than trying to predict the future and guessing what your app should do — which would be like guessing where the target is and using up all of your ammunition on that guess — waste a little bit of effort and money using “tracer bullets” to prevent wasting a ton of effort and money hitting the wrong target. I thought this was an interesting way to think about problem solving.

Invest In Yourself, Trust Your Users, and Be a Little Paranoid

These are some other key messages of the book. In the early chapters the authors talk about how programming is a continuous learning experience. If you want to be a good developer you have to adapt to the never-ending stream of new technologies, and think of education as an investment, not an expense. This is what I love the most about programming — there’s an unlimited amount of stuff to learn. Get used to reading programming books, taking courses, and attending conferences in your spare time. That’s the life of a software developer.

Another crucial lesson important enough to have been included in this book is learning to listen and respond to your users. This will make or break your product or business. This section was very much related to the previous chapter about not predicting the future. It can be hard to know when to stop tweaking your code and adding or changing functionality, and these authors suggest making your users the final authority on design decisions. The authors are big advocates of user feedback and recommend writing code that above everything else is end-user-friendly.

The last piece of advice that stuck with me is to be a little paranoid when you code. By this the authors mean you should think through every design decision you make before implementation, and patch your code as frequently as possible to introduce only small changes at a time. A key takeaway from this is book is to design for change and keep your code as flexible as possible to be able to accomodate an unknown future.

Do These and Many Other Things to Become a Pragmatic Programmer

There are of course tons of other stories and pieces of advice in the book. It’s well worth a read, especially if you’re pretty early in your programming career. The authors put programming principles in simple terms and use great analogies to make the concepts sink in. They do a great job of explaining in a lot of different ways why you should design for change, as opposed to pre-made decisions, and write code that is flexible and open-ended. Following their advice should set you on a path toward writing easier to read, more maintainable code.