OK, I’ll confess: since I subscribed to Netflix, I’ve been reading far less than I used to. Not because I don’t like it anymore—I’m just addicted to Netflix’s awesome shows ?. I guess it’s easier to clear your mind this way… But don’t get me wrong—I still do enjoy reading and I always try to find some spare minutes in my day to read a few pages. Sometimes I read to have fun, some other times I read to learn new stuff.
I’ve recently read a book by Andrew Hunt and David Thomas named “The Pragmatic Programmer: from journeyman to master“. I had been looking for a book that could teach me some tips and tricks and good practices to improve my programming skills, so when I saw it and I read the reviews on Amazon, I thought it’d be good to have it on my shelf (along with Clean Code, which I’ll review in the future… after I read it, of course ?). I liked the book quite a bit, and so I’ve decided to share with you the topics it discusses, how it’s organized, a couple of examples of the tips I liked the most, and how such a book can help you improve your WordPress skills.
Book Overview
With only 260 pages, The Pragmatic Programmer can be easily read. But don’t be fooled by its brevity: the book explains complex concepts in plain English, but if you want those concepts to really sink in, you’ll need to carefully read it and digest it. Don’t read it all at once—skim through it and get back to it when you have a particular question. Think of it as a “reference book”: you don’t need to memorize it—you need to remember the topics it covers and read what you need when you need it.
This book is a wonderful collection of “examples” in which the authors describe common problems we might face and show you how to overcome (or event prevent) them. For example, in chapter 2 (A Pragmatic Approach), the evils of duplication are discussed. I’m pretty sure you already know that “you shouldn’t duplicate code”, right? There’s nothing new, here. But the book goes one step further and explains why duplication occurs, which types of duplication exist, what you can do to spot and avoid them… That is, it offers a detailed view of things you might already know, but perhaps you weren’t fully aware of.
All tips, tricks, and comments are organized in the following chapters:
- A Pragmatic Philosophy. Introductory chapter where the authors describe the traits a pragmatic programmer should have.
- A Pragmatic Approach. Set of tips and tricks that will help improve your skills. This chapter covers topics like code duplication, prototypes, estimates, and so on.
- The Basic Tool. Here you’ll find a non-exhaustive list of the tools you need in your toolbox along with the rationale behind them. Plain text coders, CVS, or code generation tools are some examples of such tools.
- Pragmatic Paranoia. In my opinion, this is one of the most interesting chapters in the book. It covers a hard truth—your code will be imperfect, and you need to learn to live with it. Here you’ll find examples on how to reduce (but not remove) those imperfections.
- Bend, or Break. Code will change whether you like it or not. Therefore, it’s crucial you write code that can be maintained. That’s what the authors discuss in chapter 5.
- While You Are Coding. Some tips to keep in mind while coding. I think it’s a great chapter too, for it combines theory (how to estimate the cost of an algorithm) with practice (how to refactor code).
- Before the Project. If you’re one of those programmers who love to code but hate talking to customers… well, this is your chapter. Here you’ll learn how to get the requirements of the project, the problems that might arise during this process, and, again, how to overcome them.
- Pragmatic Projects. The last chapter of the book essentially summarizes everything you’ve read. Team, automations, testing… the most important pieces that create a great programmer/team are re-visited in this final chapter.
Finally, notice that the book also includes several exercises (around 40) with their related answers. You don’t need to do any of them to learn, but I think it’s good to have them anyway—they’ll help you check if you understood all the topics properly and they’ll give you the opportunity to think about your newly-acquired skills. Besides, explanations are so well-written that it’s worth reading them too!
The 3 Best Tips
There’s plenty of tips and tricks in the book that’ll help your projects succeed. All of them are excellent, but I think that an honest review needs a top-three list so… Here you have the 3 best tips in the book! (according to me, of course)
Nelio Forms
A fantastic contact plugin using the block editor. In its simplicity lies the true power of this plugin. I love it, very versatile and it worked perfectly for me.
Wajari Velasquez
? Bronze. “The Evils of Duplication”.
I’ve already mentioned this a few lines above, so you could have guessed this was one of my favourite tips. The book explains thoroughly the problems duplication entail. What I liked the most about this topic, however, is the explanation as to why duplication occurs.
According to Hunt and Thomas, most of the duplication we see falls into one of the following categories:
- Imposed duplication. Developers feel they have no choice—the environment seems to require duplication. For instance, we need to comment code, right? Which means we end up having the same knowledge in code and comments. Or we need a class that maps to a database entry, which means the associated fields of a certain class are duplicated in the database schema and the class itself.
- Inadvertent duplication. Developers don’t realize that they are duplication information. The example the authors give is brilliant: you have a class named
Linewith the following attributes:start,end, andlength. Great, right? Well,lengthis a duplication, because it can be computed using the other two properties:startandend. - Impatient duplication. Developers get lazy and duplicate because it seems easier. “Do you need a new version of this function with a slight change? Well, duplicate it and apply the tiny change!”
- Interdeveloper duplication. Multiple people on a team (or on different teams) duplicate a piece of information. You should encourage resource sharing across all your team members and teams, or else you might end up duplicating stuff.
? Silver. “It’s Just a View”.
Early on we are taught not to write a program as a single big chuck, but that we should “divide and conquer” and separate it into “modules”, each of which will have its own responsibilities. Once we have all the modules, it’s all about making them talk to each other and orchestrate the whole setup. Easier said than done…
In chapter 5 you’ll find a section covering this topic. In particular, the authors talk about the concept of “events” and they introduce the Model-View-Controller pattern. These paradigms are widely used today, specially since the rise of frameworks such as Backbone, React, or Angular. That’s why I thought this topic deserves my silver medal.
An event-driven architecture uses the concepts of publication and subscription. Essentially, this allows one component to subscribe to another one and detect when it changes, because the latter will publish an event whenever something relevant occurs. This architecture makes it super easy to decouple components—the publisher is completely agnostic about its listeners. This basic principles facilitate the creation of a Model-View-Controller app, where a view listens to the changes of a model and reacts to them by re-rendering the new state on screen.
? Gold. “Code That’s Easy to Test” and “Ruthless Testing”.
And the gold trophy goes to… ? testing! I know it’s not always easy to test your code, but we’ve already talked about it and you know it’s super important. As the authors write in chapter 6, testing plays a very important role in software development.
First, you need to make sure that your code can be tested. For that, you must write small units of code that have clear responsibilities and a well-defined set of inputs and outputs. Then, you’ll be able to write simple tests that verify that, given a certain input, you get the right output.
You also need to promote a culture of testing. All software you write will be eventually tested—if not by you and your team, then by your users. So make sure that everyone on your team’s on board and invite them to test their code ASAP. Chapter 8 summarizes this pretty well:
Most developers hate testing. (…) Pragmatic Programmers are different. We are driven to find our bugs now, so we don’t have to endure the shame of others finding our bugs later.
Not yet convinced? Tip 62 in the book says it all:
Test Early. Test Often. Test Automatically.
Pragmatic WordPress
The Pragmatic Programmer is not a WordPress-oriented book per se, but its content can be easily applied to our developments nonetheless. Just take my favourite three tips as an example—they’ll definitely help you write better plugins and/or themes. A “journeyman” programmer might be the best at writing code. A “master” programmer deeply understands the projects he works on, avoids duplication, understands and helps final users, prevents problems from happening, writes awesome documentation, tests their code…
My final tip: add this book in your own shelf. If you ever have a “philosophical question”, it might have the answer you need ?
Featured Image from the cover of “The Pragmatic Programmer: from journeyman to master“.
Leave a Reply