In short: old but gold.
Published in 1999, The Pragmatic Programmer is a book about how to become a Pragmatic Programmer. Which really means a ‘Good Programmer’.
Yes, it was published about 20 years ago. But this book still provides many insights that are very relevant to programmers or software engineers, as some people might call them these days.
You might have heard about this book before and questioned what actually it's actually about. Well, today I will share with you some of the interesting things I learned while reading the book.
There is more to being a programmer than technical skills
When reading the book's title, you might expect it to give out a lot of technical lessons. But in fact it does not. What makes this book still relevant 20 years later is that it teaches us that being a programmer is not all about technical strength. And we often overlook this fact.
The book teaches us that there is more to programming than technical abilities.
The cat ate my source code
This is the first chapter in the book and is a very interesting concept.
Remember that one day when we didn’t finish our homework and we said that the dog ate it? (Actually I don’t remember it, because I always finish my homework ?)
What that - and this chapter - teaches us is actually responsibility. When you have responsibility for something, you should be prepared to be held accountable for it.
If you make mistakes and cannot fulfill those responsibilities, you have to make up for it and find a solution. Don’t make up excuses and play the finger pointing game. You can’t just go into work and tell everybody that a cat just ate your source code.
Provide options, don’t make lame excuses.
It’s all about a broken window
In the book, there is a story about an urban area that became very messy and run-down, all because of one broken window.
This is much like our code: when we see some dirty code (which we can see like it's a broken window), we might start to think that it’s okay to let the code be dirty. That it’s okay to just go back later, which most of the time we never do.
Try not to leave “broken windows” unrepaired. When you find that kind of code, fix it up as soon as possible. When you continue to think that no one has the time to fix that broken code, you might as well go and buy yourself a dumpster just to keep your code.
What this chapter discusses is actually simple: it’s about initiative and taking care of your stuff.
Take the initiative, be the catalyst
There also might be times when you know that either something is all good or something needs to actually get done. It comes to your mind and you just think to yourself that it’s the right thing to do.
If you just keep thinking, nothing will happen. Or if you just ask for it to be on the project timeline, you might be met with huge feature development requests and technical debt. So it ends up in another year in discussion.
It’s time to step up your game. Work out what you can, don’t overdo it, but also make it reasonable. Once you got your complete idea, show it to people. They might think that “Yeah, it might be better if we had that.”
Show them a glimpse of the future and people will rally around you. Be a catalyst for change.
More so, this book also teaches us about basic fundamentals that we often forget as programmers.
Sometimes, the more we delve deeper and deeper into our work, the more often we forgot about the basic things that we learned a long time ago.
Busy chasing features and new tech improvements, we often forget that there are actually a lot more things that we need to pay attention to beforehand before going deeper.
Clean code
One of the most basic principles we often forget about is clean code. As features are piling up more and more, the codebase become fatter and technical debt rises.
But we must always remember to keep our code consistent and clean every time we write it.
One of the things that is mentioned in the book is the DRY principle (Don’t Repeat Yourself). It is related to code reusability. Duplication is evil and that's the truth. Duplicate code will make maintaining your code very hard, and it can cause confusion when you need to change a feature or fix a bug.
Remember that time when you needed to fix some of your code? And you realized that there was code that was very similar to the bit you just changed? So then you gotta change that part too, and another too, and then maybe this bit too…you get the picture.
Find the correct tools
Like a woodcutter, finding the correct and proper tools is very important. Before a woodcutter starts cutting trees. they have to decide - do they need a chainsaw? Or is an axe good enough? Or maybe there is a brand new lightsaber they can use. But using kitchen knife might take some time to cut down a tree.
It's similar for programmers: this book teaches us that it’s very important for us to find the proper tools before we start working (like a good code editor). We shouldn't jump right to coding.
For example, it’s actually possible to code using Windows notepad and compile it using the console. But is it the right tool for you? Try to find the best editor that you are most comfortable using. Learning and mastering it and it will increase your productivity by several times.
There are several editors mentioned in the book, such as Emacs or Vim. But nowadays you can find more modern code editors such as Visual Studio Code. Find one that suites you. It's like your taste in coffee – some people prefer lattes and others prefer cappuccinos.
Don’t program by coincidence
This is one very important point noted in the book. In all of our programming journeys, there have likely been times when we were just coding blindly and unexpectedly… and somehow it just worked.
You probably weren't sure what you were actually doing, so you kept adding more and more code and it still worked. That is, until one day when there was an issue and you tried to remove some chunk of code and it completely broke everything. And you were not sure which piece caused it.
Relying on unknowns is very dangerous. When you are not sure what the code is supposed to do, try to simplify it and make sure that the code is reliable in its own right, not just reliable by chance.
Rely only on things you are sure of. Don’t program by coincidence.
Unit test
Testing is a hot topic these days. And yes, it was also an important topic 20 years ago (and it will always be).
But sometimes people forget about unit tests these days. They might have just finished their code and they assumed everything was okay...until the code ended up broken in production because of edge cases.
In order to maintain stability and refactor safely, we always need to keep our code protected by writing unit tests. And it’s never enough if your tests only cover the happy path. Perform ruthless testing on your code, and remember that your code is not finished until you've covered every available test.
Unit testing will help you be confident that your piece of code is truly done.
Taking ownership
There's one last thing I want to talk about. As we know, programmers like to leave ‘legacies’ behind, in the form of code. And yes, most of the time it’s bad.
Being a programmer, we ought to take pride in our own work. We should be proud of the responsibility we've been given and the piece of code we have been working on.
When we are finally able to take pride in our code and own it, we will be able to leave a good legacy behind. And people will see our code as a signature. When they see our code, they'll know that it will be solid and well-written, by a professional.
Finishing up
There are even more topics covered in this book that I haven’t discussed here, such as Requirements and Teamwork. If you are interested in exploring these topics, you should try to find and read the book!
Just a note, however: as much as I liked the book, some stuff just didn't seem relate-able, looking at how old the book is (20 years old). It talks about old languages such as Prolog, and speaks about OOP like it’s a really new concept - so these oddities just don't seem right.
But it can’t be blamed since it's already a couple decades old.
Aside from that most of the stuff covered in the book is still quite relevant to the current age of Programming, like those topics I covered above.
If I was trying to sum everything up in this book, I'd say it basically covers everything I have ever read on the Web about becoming a better engineer.
Thanks for reading my article about The Pragmatic Programmer! Hopefully it has given you some insight into your journey as a Programmer or Software Engineer. And grab yourself a copy of the book if you are interested in learning more.
P.S. I wrote this article on my own, without any means of advertising or marketing from a third party. The cover photo was taken from amazon's site.