Revisiting The Pragmatic Programmer 10 Years Later
Oct 4, 2019
Walter Manger
3 minute read

As with many non-fiction books, The Pragmatic Programmer can be distilled to about 1% of its page count. That’s not a hit on the authors or the publisher, that’s just how non-fiction books work in my opinion.

This book gives you all the tips you need to become a master Code Craftsman, but it is missing something very important.

Andrew and David don’t discuss a programmer’s well-being.

Programmers need to take care of themselves - their physical and mental health, relationships, and finances.

We’ve grown to accept positions that require extra working hours, which, reduces our salary, strains our relationships, and causes our health to deteriorate. We idolize peers, some of which are not well themselves. We experience imposter syndrome. We feel pressure to always be ready for the next interview, so even more time needs to be spent on being interview ready.

With the actual programmer in mind, I suggest adding these tips.

  1. Find a position that is invested in you, not your programming ablilties
  2. Schedule time for physical activity and put it on a calendar. I recommend a minimum of 30 min/day, 3 days/week. You are not available at these times.
  3. Schedule time for managing your finances and put it on a calendar. You are not available at these times.
  4. Schedule time for managing your relationships and put it on a calendar. You are not available at these times.
  5. Make it clear that your off hours are not flexible. Don’t miss out on life because you’re pushing code.
  6. Practice Deep Work to feel less imposter syndrome

Here are my top 10 tips from this book that I think still hold true today.

8. Invest Regularly In Your Knowledge Portfolio

Schedule this weekly. If you are an employee, ask to incorporate this into your workday. 30 minutes 3 days a week would do wonders for you and the company that you work for.

14. There Are No Final Decisions

All Software is a living, breathing organism. Your decisions have to be logical for the current need and flexible for future needs.

21. Use The Power of Command Shells

Use the terminal, as it is faster in most cases, and it is scriptable for when you only want to write it once.

22. Use a Single Editor Well

A speedy one that does not slow you down by forcing you to use your mouse.

24. Fix the Problem, Not the Blame

Problem solving > finger pointing. Don’t waste time on blaming when you should be fixing something.

27. Don’t Assume It, Prove It

Prove your assumptions in the actual environment (real data, real infrastructure). This is huge for work in the cloud.

36. Minimize Coupling Between Modules

Ensure that your code is testable in the first place. Any external services should be injected in.

40. Design Using Services

Indeed! This goes hand in hand with #36.

48. Design to Test

Bravo! This goes hand in hand in hand with #36 and #40.

61. Don’t Use Manual Procedures

Automate the boring parts. Anything done manually more than once is prime for some sort of automation.

BONUS 63. Coding Ain’t Done ‘Til All the Tests Run

Agreed. Don’t find a way around the tests either. If the tests cause your build process to be slow, find a way to speed it up. Whatever you do, do not disable them. Figure it out. Don’t abandon all the code written to ensure code is of quality because you are impatient.