One of the most thought-provoking activities in the Read to Lead Challenge was: Read a book like a critic. That prompt opened up a deeper way for me to engage with books—not just passively absorbing their content, but actively reflecting, questioning, and considering how I’d recommend (or not recommend) them to others.
(If you prefer listening to reading, and with added images…)
I approached this challenge with a few re-reads of influential books. First, Working Effectively with Legacy Code. It’s been several years since I first read it, and I wanted to reassess whether I still supported my recommendation. The answer? Absolutely. Most of my testing practices stem from the ideas presented in that book. Sure, some code examples haven’t aged gracefully, but the approaches remain firm. If anything, it’s due for a second edition—same message, updated tooling to appeal to younger audiences.
Then there was Head First Design Patterns. Again, I was asking myself: would I still recommend this to someone wanting to learn design patterns? Yes. And also… maybe. Some chapters lean heavily into Java-specific implementations, which don’t always translate cleanly for developers in other languages. Still, the book excels in teaching the patterns themselves, and that’s what matters most. Some later chapters could use more depth, but overall, it holds up.
What I appreciated most in this activity wasn’t just revisiting the content—it was thinking about the mindset of a critic. I was drawn to the nuance between criticism and critique. In Brazilian Portuguese, we use the same word for both, and it usually implies negative, implying someone is tearing something down. I discovered a helpful distinction in English: critique implies constructive analysis; criticism often means judgment.
In A Complaint Free World, Will Bowen writes:
Criticism is defined as pointing out another’s faults in a disapproving way. Therefore, ‘constructive criticism’ is an oxymoron. To be constructive is to build up. To criticize is to tear down. You are never being constructive when you criticize someone.
That made me want to dig deeper into these distinctions.
Here’s how I now think of it:
- Criticism is more casual and often points out flaws, sometimes without depth.
- Critique is a thoughtful, often balanced analysis that includes both positive and negative aspects and is typically intended to improve the subject under review.
Another layer I’ve been considering: Am I criticizing the work, or the author? Or am I reacting simply because the book wasn’t for me? That distinction matters. When I read or hear someone critique a book, I now try to assess: are they focused on the content and structure of the work itself? Are they being overly critical of the author’s tone or style? Or are they frustrated just because the book didn’t meet their needs or expectations? That framing helps me better understand both my reactions and those of others.
I liked thinking of a critic not as someone who tears a book apart, but as someone who brings an analytical lens and aims to improve understanding. A quote by Ryan Holiday helped shape this idea further: “Engage with the most charitable interpretation of the argument and respond to that.” It reminded me of improv rules—”yes, and…” or even better, “yes, because…”
Take The Power of Your Subconscious Mind, which I read when I was 12 or 13. Reading it a few years later, some of my teenage attitudes would have prevented me from enjoying the book. Re-reading it in my 20s, I might have said, “Yes, it’s good, but it’s too preachy.” But reframing that in my late 40s, did I like the book? “Yes, and I’m glad I read it when I did”. Or even better, “yes, because it helped me develop the skill of visualizing outcomes”. That makes the engagement more generous and helpful.
Holiday’s challenge also encouraged checking out one-star reviews of books you love. I tried that with Agile Principles, Patterns, and Practices in C# by Uncle Bob. Some reviews said it wasn’t very C#-specific or criticized the structure. Fair. But I also saw criticism that seemed to miss the point entirely. The book isn’t about C# syntax—it’s about timeless principles. Those principles shaped many of my talks and blog posts in the late 2000s.
Another example: Badass: Making Users Awesome. One review called it “useless and amateurish,” offering no clear feedback. Another claimed it presented “basic psychology and wasn’t for anyone smart”. Well, call me dumb then—I learned a lot from it, and I’ve seen it help others, too. If you want academic depth, this might not be your book. But if you’re looking for clear and accessible guidance, it delivers.
Reading like a critic made me more thoughtful—not just about books, but how I talk about them. It’s easy to skim the surface and make snap judgments. It’s more useful (and respectful) to engage deeply, ask what holds up, what’s missing, what could improve, and most of all, what you learned and when it mattered most.
That is the essence of reading better.
Leave a Reply