Pragmatic Thinking &  Learning

This book introduced me to the Dreyfus Model of skill acquisition, with five levels:

1. Novice – just trying to accomplish the immediate goal; requires a recipe
2. Advanced Beginner – still requires a recipe; often rejects context
3. Competent – can troubleshoot, but has difficulty identifying the right problems to focus on
4. Proficient – beginning stages of self-reflection and approach correction
5. Expert – very good at targeted and focused pattern matching

Level achievement exists within a domain, not across domains. Being a Proficient Python programmer doesn’t make you a Proficient baker, public speaker, or even JavaScript programmer.

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.