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.
- Find a position that is invested in you, not your programming ablilties
- 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.
- Schedule time for managing your finances and put it on a calendar. You are not available at these times.
- Schedule time for managing your relationships and put it on a calendar. You are not available at these times.
- Make it clear that your off hours are not flexible. Don’t miss out on life because you’re pushing code.
- 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.