How strongly do I recommend Pragmatic Thinking & Learning?
8 / 10
This book is fundamentally about how learning happens through the perspective of software engineering.
For engineering managers, Pragmatic Thinking & Learning provides a good framework for thinking about states of employee knowledge, understanding, and capabilities – the foundation of performance reviews.
This book introduced me to the Dreyfus Model of skill acquisition, with five levels:
Novices and Advanced Beginners often confuse design patterns with recipes. I’ve been there. They have a difficult time understanding the more general nature of design patterns – that design patterns aren’t plug-n-play and require context.
Experts in the Dreyfus Model rely heavily on intuition. These engineers solve problems quickly because they identify patterns they’ve experienced before.
In my experience, Expert engineers sometimes need coaching and encouragement to explain their rationale.
The Competent and Proficient engineers they work with don’t have the same intuition and greatly benefit from slowing down and explanation. Expert explanation helps the Competent engineer focus on the right problems.
This is a bit counterintuitive, but worth understanding.
I’ve made the mistake of assigning an Expert engineer to onboard a new engineer. Intuitively an Expert makes sense because they know the whole system and can provide context.
But in reality, the Expert has forgotten what it’s like to be a Novice – and when it comes to onboarding a new engineer into your complex system, in many ways everyone is a novice.
New engineers might understand the technology, but might not understand your domain well and almost certainly don’t understand the system architecture or implementation patterns yet.
You’re better off having a Competent engineer lead new people through onboarding because they still remember what it was like to be a novice.
Software engineers get excited about building new things. We start thinking about the right frameworks and libraries to use before we really understand the problem. We start listing target delivery dates, to the great satisfaction of our managers and stakeholders.
But early on, we don’t really understand the project yet. Unknown unknowns abound.
To the extent possible, we should defer major decisions until later in the project because at that point we’ll know much more.
Deferring decisions makes people uncomfortable. Your manager probably won’t feel great about an open ended timeline. Ranges really help mitigate fear from uncertainty. As the project progresses, those estimates and decisions will gain clarity and accuracy because we’ll know so much more.
Uncle Bob makes similar points in Clean Architecture looking more specifically at technical decisions.