What i learned from reading ‘The Pragmatic Programmer’
Old but gold.
Published in October 1999, about 20 years ago.
The Pragmatic Programmer is a book about how to become a Pragmatic Programmer, which in short means a ‘Good Programmer’.
Published in the ancient era, about 20 years ago. Yet, this book still provide many insights that are very relevant to Programmers these days or some might call them Software Engineer.
Some people might have heard about this book before and question what actually is it about.
Today, I will share on some of the interesting learning across reading the book.
There is more than technical skill to programmer.
When reading the title, you will expect the book to give out a lot of technical lesson. But it is actually a big NO-NO. What makes this book can still being relevant for 20 years is that, it taught us that being a programmer is not all about technical strength, in which we often overlook.
It taught us that there is more to it than technical strength.
The cat ate my source code.
It is the first title in the book and it makes a very interesting concept of it.
Remember the day when we didn’t finish our homework and we said that dog ate our homework? (actually i don’t remember it, because i always finish my homework 😜)
What it actually taught us is actually about responsibility.
When you have held the responsibility for something, you should be prepared to be held accountable for it.
If you make mistakes and cannot fulfill those responsibility, you gotta make up for it, find a solution for it. Don’t make up excuses and play finger pointing game. You can’t just go up 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 short there is a story about an urban area that became very messy, all because of one broken window.
Much like our code, when we see some dirty code (which we can see like broken window), we will start to think that it’s okay to keep the code dirty and it’s okay to just go back later, which we most of the times never done. Try not to leave “broken windows” unrepaired. When you find those kind of codes, fix it up as soon as possible. When you continue to think that no one got the time to fix those broken codes, might as well go and buy yourself a dumpster just to keep your code.
What this story talking about is actually simple, it’s about initiative and careness.
Take the initiative, be the catalyst
There also might be times when you know that something is good or something needs to actually be done. It comes up in your mind and you just think to yourself that it’s the right thing.
Keep thinking and nothing will happen, or ask for it to be on the project timeline and you will be met with huge feature development and technical debt and it will end up in another year 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 it, show to people and they might think that “Yeah, it might be better if we have that..”.
Show them a glimpse of future and people will rally around you.
Yes, be a catalyst for change.
More so, this book also taught us about basic fundamentals that we often forget as a Programmer.
Sometimes, the more we delve deeper and deeper into our work as a Programmer, we often forgot about some basic things that we have learned a long time ago. Busy chasing feature and new tech improvements, we often forget that there are actually a lot more things that we need to pay attention beforehand before going deeper.
Clean code
One of the most basic principle and we often forget about is clean code. As features are piling up more and more, codebase become fatter, technical debt is rising. But we must always remember to keep our code consistent and clean everytime. One of the things that is mentioned on the book is regarding DRY principle (Don’t Repeat Yourself).
This is very related to code reusability. Duplication is evil and it’s the truth. Duplicate codes will make maintainability very hard, causing confusion towards feature change or bug fixing.
Remember the time when you need to fix some of your codes? And you realized that there are codes that are very similar to the one you just changed, and you gotta change that one too, and another one too, and you maybe this one too…
Finding the correct tools
Like a woodcutter, finding a correct and proper tools is very important. Before a woodcutter start cutting trees. Do the woodcutter need chainsaw? or axe is good enough? or maybe there is a brand new lightsaber for use. But using kitchen knife might take some time to cut a tree.
Similar to programmer, this book taught us that it’s very important for us to prepare a proper tool beforehand and don’t jump right to coding.
By tool here, what i meant is code editor.
It’s actually possible to code using windows notepad and compile it using console. But is it proper tool for you?
Try to find the best editor that you are most comfortable for, learn and master it and it will increase your productivity by several times.
There are several editor mentioned in the book such as emacs or vi.
But nowadays you can find more modern code editor such as visual studio code. Find one that suites you the most, like your taste in coffee, some people prefer latte and some will prefer cappuccino.
Don’t program by coincidence
This is one very important point noted by the book. In your programming journey, i’m pretty sure that there are times when you are doing code blindly and unexpectedly… it just works!
You are not sure what you are actually doing, and you keep adding more and more code there and it still works.
Of course, until one day there is an issue in the code and you try to remove some chunk of code and it completely break the whole code. And you are not sure which one is causing it.
Relying on unknown things 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 as it is, not unexpectedly reliable.
Rely only on thing you are sure at, don’t program by coincidence.
Unit test
It has been a hot topic around these days, and yes, it was also a precious topic 20 years ago and it will always be.
Unit test is what people always forget around these days. They just finished their code and assumed everything was okay, until the code ended up broken in production because of edge cases.
In order to keep stability and refactoring safe, we always need to keep our code guarded by making unit tests. And it’s never enough if your code only cover the happy path. Do ruthless testing on your code, your code is not finished yet when your test haven’t covered every available tests.
Unit test will help you to keep on your confidence that your piece of code is truly done.
Taking ownership
One last thing i want to talk about
As we know, programmer likes to leave ‘legacies’ behind, in the form of codes. And yes, most of the times it’s bad.
Being a programmer, we ought to take pride on our own work. We should be proud of the responsibility and the piece of code that we have been working on.
When we finally able to take the pride of our code ownership, we will be able to leave a good legacy behind. And people will see our code as a signature, that our code will be expected to be solid and well-written, like a professional.
Finishing up
There are even more things covered in the book that i haven’t covered it here such as Requirement and Teamworking, which if you are very interested in exploring you should try to find and read the book!
But as much as I like the book, some stuff just doesn’t seem relate-able, looking at how old the book is (20 years old). Talking about old language such as prolog and about OOP like it’s a very new things just doesn’t seem very right. But it can’t be blamed since the book is already very old.
Aside from that most of the stuff covered in the book is very relevant to the current age of Programming, like covered above.
If i might sum everything up in this book, it’s basically everything i have ever read in the Web about becoming a better Engineer.
Thanks for reading my article about The Pragmatic Programmer!
Hopefully my article can give some insight on your journey as a Programmer (or maybe some people call it Software Engineer these days). And grab yourself a copy of the book if you are very interested.
P.S. I’m writing this article on my own, without any means of advertising or marketing from third party.
