The Pragmatic Programmer

Authors: Andrew Hunt, David Thomas
Date Read: October 4, 2015
Rating: 6/10
ISBN: 978-0201616224

This is probably one of the most classic programming books that is frequently recommended to programmers by programmers. I catagorize this type of book as Programmer’s Self-Help. Some will find it helpful, others look for more actionable advice. I read this when I was about 2 years into my software engineering career.

Here are my top 10 insights 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.