The Pragmatic Programmer From Journeyman to Master

I enjoyed this book. It certainly wasn’t perfect. I would still recommend The Pragmatic Programmer, especially to new programmers. At times it felt like they didn’t have enough to say to cover the length of the book (violating DRY… ;)), so I skimmed those parts. Especially towards the end. I particularly enjoyed that they took more nuanced and pragmatic (ha) stances to concepts and ideas. They weren’t overly prescriptive, but explained why you might go for something, and why you wouldn’t. This is refreshing to the almost ideological conversations around tech. Most of the content, while outdated to varying degrees, is still useful. At least the mental model and principles it conveys. Go a bit deeper and try to understand the problem the idea is actually solving, and you’ll get much out of this book.

Completely wrong, to the point of making me so frustrated that
I couldn't finish the book, but very nicely written.

‘Programming is a craft. At its simplest, it comes down to getting a computer to do what you want it to do (or what your user wants it to do). As a programmer, you are part listener, part advisor, part interpreter, and part dictator. You try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice.’ ‘Great lawns need small amounts of daily care, and so do great programmers. Management consultants like to drop the word kaizen in conversations. "Kaizen" is a Japanese term that captures the concept of continuously making many small improvements.’ ‘One broken window, left unrepaired for any substantial length of time, instills a sense of abandonment…so another window gets broken. People start littering. Graffiti appears… In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.’ ‘In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them. You sketch out an overall shape, paint the underlying environment, then fill in the details.’ ‘Think of the code that needs refactoring as a "growth." Removing it requires invasive surgery. You can go in now, and take it out while it is still small. Or, you could wait while it grows and spreads—but removing it then will be both more expensive and more dangerous. Wait even longer, and you may lose the patient entirely.’ ‘All software you write will be tested—if not by you and your team, then by the eventual users—so you might as well plan on testing it thoroughly.’ ‘Great software today is often preferable to perfect software tomorrow.’