Take aways from reading The Pragmatic Programmer

The Pragmatic Programmer is one of the most well-known books for software engineers. I read it for the first time 12 years ago, and it was relevant to the decisions I’ve taken in my career.

The book brings actionable tips you can apply daily to become a better engineer. It’s not only about technical topics but also about handling specific situations, working within a team, how you can help others, etc. Andy Hunt and David Thomas did a great job summarising many pieces of advice in a single book in super easy and fun reading.

Fast-forward to 2021, I saw this book on my Kindle shelf and got curious about how it aged for me and how its ideas have shaped my life as an engineer. That’s why I wanted to share my key takeaways.

Before going into them, I have a disclaimer: this reading doesn’t replace the whole book. The idea is to give you an idea of what I learned and connect it with my decisions during my career. Hence, my message is: please, read the book, not only this short post.

Rethink and evolve

In my early days as a programmer, I heard a comparison between software engineering and building construction for the first time.

Even though many people highly accepted it many years ago, this comparison was a bit misleading as the code is constantly changing, evolving and even deleted, which is not expected when building a skyscraper. You can’t quickly move a building 2 meters to the right.

As the products change, the code does the same. It’s expected. The requirements change, companies pivot to new revenue streams, or the product becomes a huge success that needs a new architecture to support your customer base. As a result, a pragmatic engineer should continually rethink and keep the code easy to change.

The authors made their point by comparing software engineering to gardening, and that’s more accurate as both are organic and concrete. The continuous process of caring for your plants is similar to making changes to your codebase. You can do many things to maintain your codebase sane, such as rewriting and rearchitecting, but one concrete activity engineers should keep an eye on is the refactoring practice.

Refactoring is not a one-off thing. This practice must be done continuously as a small-scale activity and safely as we’ll not change the external behaviour but how it was implemented. Therefore, a good automated test suite helps a lot.

Also, I’ve learned from this book that pragmatic engineers should understand when to refactor. It’s easy to feel that everything is a mess and should be changed now. However, we’re not doing tech things just for tech purposes. We’re supporting a business, especially if you’re working for a tech-enabled product, so the challenge is to move fast and keep the codebase sane as soon as possible since it will be a more significant time investment when the codebase grows.

Naming things

It’s pretty simple, isn’t it? If you’re a software engineer, there’s a non-zero per cent chance you’ve already faced some struggles while naming variables, methods and classes.

When writing code, you need to stop and think about the motivation of this piece of code and name things according to what they do. It seems obvious, but the book mentions the science behind it by showing the Stroop Effect.

In general, I usually follow three rules about names from the book:

“Honor the culture” means programming languages usually have their conventions, such as using camelCase or snake_case or allowing a subset of Unicode in method names. So, you should try to follow their conventions.
“Consistency”. Connecting this topic to DDD, you must try using domain names you’re into - yes, ubiquitous language, and it’s better to be specific than generic. That will facilitate communication within your team and help not make every engineer use different names for the same concepts.
“Rename often”. Nowadays, there are a lot of tools to make renaming easier, even in interpreted languages like Ruby. So, in your continuous refactoring practice, ensure you’re also renaming things accordingly.

Build your knowledge portfolio

Investing in your knowledge is essential to keep you updated, especially in a fast-paced software industry.

This chapter compares investing in your knowledge with financial investments. Diversification, continuous reviewing, and balancing between high and low-risk investments are examples we should follow to build our portfolio. Also, it mentions that these portfolio management skills are totally in our control and, therefore, can be learned.

There are actionable items I’ve taken from the book to my career. I tried to work with different environments earlier in my career, and it didn’t matter if it was a front-end project or some infrastructure tweaks.

Also, I’ve learned that we need to be critical of what we read and hear while building our portfolio. You could watch a presentation about how Netflix scaled their infrastructure and apply the same approaches to your company to feel like you’re a rockstar. That’s precisely the opposite of what the book says. Therefore, you should understand your context, tradeoffs, the problem you’re trying to solve, think critically, etc.

So, the takeaway is: invest in your knowledge regularly, expose yourself to different problems, keep yourself updated, but also think critically about what you should read and hear.

The cat ate my source code

This is the funny way the authors describe that mistakes and problems happen. Indeed, shit happens constantly during software development, even with the best projects. For example, you can find late roadblocks or something unexpected happens with a piece of infrastructure.

However, how pragmatic engineers deal with those situations is what matters. They deal with them professionally, which means being honest and taking responsibility.

As the author mentions, pragmatic engineers are not afraid to admit ignorance and mistakes. This behaviour makes your teammates trust and rely on you, and that’s essential for your career, the success of a project, and building up a healthy environment.

Finally, there’s another relevant piece of advice that I’ve tried to take over my career:

Don’t blame someone or something else or make up an excuse. Don’t blame the problems on a vendor, a programming language, management, or your coworkers. Any and all of these may play a role, but it is up to you to provide solutions, not excuses.

It’s not only about coding

Getting stuck on the idea that your job is just about getting a requirement and writing code is easy. It wasn’t different to me.

When I started programming professionally back in 2008, I couldn’t count how many times I complained that the “requirements are not well defined” or “I can’t do X because the customer doesn’t know what he wants”. That was definitely a wrong mindset, as I was being paid to solve problems in an ambiguous environment and not just write code.

After reading the book and paying more attention to what was happening around my daily job, I understood that pragmatic engineers always seek the big picture, fill the gaps and deal with uncertainty. That’s the nature of our work. We need context and domain knowledge to tackle the problems effectively.