Supporting your mid-level engineers
Previously, I discussed why mid-level engineers need technical breadth. Now, let’s flip perspectives and look at it through the lens of a software engineering leader.
How do people learn?
Understanding the Dreyfus model helps explain why mid-level engineers need real-world challenge to advance beyond rule-driven thinking and avoid becoming “expert beginners”.
Here’s a quick summary from the original paper.
The key part here is that “as the student becomes skills he depends less on abstract principles and more on concrete experiences1”. This is made clear in the final table in the paper.
Recollection: At novice levels, people require on context-free rules and facts they can recall regardless of the situation. As expertise develops, recollection becomes more situational. Experts can recall relevant experiences and patterns that are specific to the context they are working in. For example, as a novice you might learn a rule that database connections should be closed when done, but as a senior you might recognize that in this context the cost of opening and closing connections isn’t warranted; time to break the rules and introduce connection pooling.
Recognition: Novices break down situations into separate isolated components they recognize individually. Experts develop holistic recognition; they see the whole situation as an integrated pattern rather than separate pieces (chunking). For example, when debugging a problem, a novice might look at the individual errors, whereas a more experienced developer will connect the symptoms and call back on past experiences (” it’s an N+1 query problem”).
Decision: Beginners make decisions by analytically working through rules. Experts make decisions intuitively, drawing on their deep experience without conscious analytical steps. For example, a beginner might go through a mental checklist (do I need multiple implementations? do I need to create objects? Therefore, I should use a factory pattern), whereas a more experienced engineer will intuitively make the connections and use a factory pattern.
Awareness: Novices must consciously monitor their actions and the situation around them. Masters’ develop absorbed awareness. They can perform the skill whilst capable of other activities simultaneously. I’m (forever) learning guitar, and if I play a hard song, I can’t sing along. Same sort of thing!
The expert beginner
Erik Dietrich has a superb article, “How Developers Stop Learning: Rise of the Expert Beginner”. Please go and read it, I’ll wait!
You don’t want to get folks stuck as an expert beginner. What can you do to avoid creating expert beginners in your organization?
Helping folks develop
Obviously, this isn’t a set of rules; I don’t know your context, but these are some things I’ve seen work.
Feel the problems before introducing solutions
Mid-level engineers need exposure to messy, real-world problems before abstract principles make sense. Instead of teaching "SOLID principles" in isolation, have them refactor a legacy codebase where they discover why these principles matter. For example, when they struggle with a 2000-line class that's impossible to test, the Single Responsibility Principle suddenly clicks. Or when adding a feature requires modifying 15 different files, they viscerally understand why dependency inversion matters.
Often, I think our industry tries to teach things like SOLID, TDD or so on with tiny examples (I’ve definitely done this). And then we act surprised when folks aren’t able to adapt the techniques to codebases with 100x as much complexity or size. Feel the problem first before introducing the solution.
Room for experimentation
The jump from competent to proficient requires developing personal heuristics - those "something feels off" moments that experts have. Engineers need environments to build this intuition where the cost of failure is low. Code reviews on non-critical services, spike investigations where "failure" is expected, or sandbox projects where they can experiment with different architectural patterns all serve this purpose.
At Autonomy, I created tools to help make my job easier (fuzz testing). Over the years there it proved super valuable, not just because it found bugs, but because every few months I’d put it down and come back to it and realize all the mistakes I made. I could then redesign it, learn and repeat the process.
Other ways to do this might be to challenge folks to have architecture discussions for hypothetical features or create workshops where they analyse problematic code without the pressure of fixing it immediately. The goal is exposure to many patterns, not immediate solutions.
Make thinking visible
Intuition develops from seeing many examples of expert judgment. Encourage senior engineers to make thinking visible by having them narrate their debugging process, explain why they chose one design over another, or think aloud during code reviews. The goal isn't to create more rules but to show how experts blend multiple considerations fluidly.
We recently reached out 500th Architecture Decision Record in my current company. That’s 500 pull requests full of discussion about software design decisions. A hugely valuable resource.
Another suggestion is regular "decision archaeology" sessions - examining past technical decisions, what information was available at the time, what trade-offs were considered, and how it played out. This builds the pattern-matching database that powers intuition.
Embrace the suck
The expert beginner trap often comes from premature optimization - applying rules without understanding their boundaries.
Combat this by assigning problems slightly beyond their current rulebook. When their usual patterns fail, they're forced to think more deeply. As a leader, deliberately assign tasks just outside comfort zones to force critical thinking beyond those familiar patterns. Techniques like pairing / mobbing can (when done badly) shield folk from making leaps of learning. Sometimes struggling with a problem to solve is exactly what folks need.
Conclusion
The journey from mid-level to senior engineer isn't about learning more rules. It's about developing the intuition to know when to break them. And this is why it’s a harder transition! As engineering leaders, we need to cultivate engineers who can navigate ambiguity, not just follow increasingly sophisticated playbooks.
The expert beginner trap is real. These engineers ship code and follow best practices, but plateau when contexts shift. The strategies I've outlined take time and engineers will get frustrated when their rulebook fails them. But it's worth it. Engineers who make this transition become force multipliers. And as AI handles more rule-based work, these human capabilities (intuition, judgment, contextual thinking) become our competitive advantage2.
I really want to make clear that those concrete experiences are the important bit. Intuition is the shortcut, but I don’t think you can fast-forward to intuition without a deep understanding of the theory, practice and when that goes out of the window!
That sounds like an AI generated sentence, right? Sorry!