Books for software engineers and managers

The Pragmatic Programmer

The Pragmatic Programmer

Your Journey to  Mastery

by Andy Hunt and Dave Thomas

Categories:
Star Engineer,
New Engineer

How strongly do I recommend The Pragmatic Programmer?
6 / 10

Review of The Pragmatic Programmer

Although The Pragmatic Programmer is considered a classic and is found on every must-read list, I finished this book feeling disappointed.



Regularly invest in your knowledge  portfolio

Serious investors make regular investments in their knowledge. Knowledge investing is a habit. Small, regular investments go extremely far particularly when you consider the power of compounding interest.

Reading is the most obvious example. The number of pages you read per day roughly equates to books per year. Read 10 pages per day? That’s 10 books.

If those are non-fiction books in your domain, you’ve greatly improved your knowledge with minimal investment. In reading, compounding interest occurs when you borrow an idea from one domain and apply it to another, as I’ve experienced by diversifying my reading selection – engineering, history, business, design, culture, and sports books cover my shelves.

Software is more like gardening than  construction

Some plants thrive, others die, and some unexpected plants violently take over your garden. Curation and eternal vigilance matters to gardens.

I’ve fully switched to the gardening metaphor.

The construction metaphor is dangerously inaccurate. Too many software engineers use the construction metaphor to justify rewrites, pointing to foundational issues in the codebase.

They’re not thinking about protecting living organisms. They just want to feel the satisfaction of sledgehammer demolition and smell new construction. When you apply the gardening metaphor, their explanations become less coherent, which also explains why so many rewrites fail.

Distrust product silos where specs get handed over to  engineers

The authors write, “Distrust environments where requirements are gathered, specifications are written, and then coding starts, all in isolation.”

As an engineering leader, one of your most important jobs is to break down the walls between design and engineering. Andy Grove gets at a similar concept in High Output Management, which I’ve called shifting left on quality. To my mind, The Pragmatic Programmer mentioning this also reflects a shift in the approach from waterfall to more agile methods.

The Pragmatic Programmer