Actually, I’ve written about pragmatic programmers. In that article, I wrote about the definition of pragmatic, what makes a programmer pragmatic, and the characteristics of a pragmatic programmer. In this post, I will make ten takeaways from the book The Pragmatic Programmer, which can be considered as a continuation of the previous article.
As programmers, we want to be spending less time in purposeless meetings, fixing annoying bugs, and more time doing what we love, which is actually programming away on fun solutions to interesting problems.
I just finished The Pragmatic Programmer by Andrew Hunt and David Thomas, and it’s a very worthwhile read on how we can be more effective as software engineers, especially those of us who are working in teams.
Here are the ten takeaways from The Pragmatic Programmer:
No dogma
A pragmatic programmer is technology-agnostic. Meaning they’re not wedded to any particular language toolset or operating system. It’s fine to have preferences, but we need to see each set of circumstances uniquely and apply a solution appropriately.
Great power, great curiosity
Software is among the most autonomous professions there are. Good engineers don’t take this agency for granted. They care about their craft and think about their work.
Good-enough software
The “good enough” doesn’t mean sloppy. We must meet the user’s requirement, but no more than that because time is precious. And don’t forget to involve the user when making trade-offs.
No broken windows
Quality is a team issue. Leaving issues unfixed sends bad signals. A team should not tolerate broken windows. As a good engineer, you need to set an example by continually refactoring and fixing bugs when you encounter them.
Let it crash
Dead programs don’t lie. Crashing as early as possible prevents catastrophes from slipping by into production. Overly defensive programming is dangerous. Let it crash.
Decouple your code
If everyone has to attend a meeting because no one’s sure what will be affected by a change, the code needs decoupling. Decoupled code is easier to change.
Coding is non-mechanical
Coding is not just a matter of blindly transcribing the design into executable statements. If our software is to enjoy a long healthy life, we need to continually think about improvements.
Keep it simple
There are many reasons to keep design simple. It’s easier to change and maintain, but also safer.
Higher code complexity means a larger attack surface. Less code means fewer bugs and fewer opportunities for security holes.
Be a therapist
Part of being a good programmer is helping the client figure out what he/she really wants. Project requirements are learned in a feedback loop between both parties. Never trust a customer’s first statement of needs. Help them clarify what they really need.
Don’t panic
If coding feels like an uphill battle, take a step back. It’s probably harder than it needs to be.
Maybe the design is wrong? Maybe you’re solving the wrong problem?
Draw some doodles, take a walk. The solution will come. Let friction foster simplification.
In conclusion, pragmatic programmers embody responsibility. They value quality, but not complexity.
Above all, being a pragmatic programmer is about bringing the whole team together, helping your peers thrive and improve in the process.
This article is part of the 30 Day Writing Challenge. I’ll challenge myself to write whatever comes to mind.