There is a moment in every engineer's career - usually around the third or fourth year - when something subtle and dangerous begins to happen. Problems start looking familiar. Patterns emerge before the requirements are fully read. Solutions crystallise before the problem is fully understood. We call this experience. We celebrate it. We pay premiums for it.
But I want to propose something uncomfortable: this familiarity might be the beginning of a slow blindness.
Consider what happens when a senior engineer encounters a new challenge. The mind, trained by years of similar encounters, immediately begins pattern-matching. "Ah," it whispers, "this is like that authentication problem from 2019. This is basically a caching issue. This is just another variant of the distributed consensus problem I solved at my last company." The pattern locks in. The solution pathway illuminates. And the engineer, confident and efficient, begins building.
But here is the question that haunts me: what if the problem only resembles the remembered pattern? What if there are subtle differences - differences that matter enormously - that the pattern-matching mind has already discarded as noise? The expert has stopped seeing the problem. They are now seeing their memory of a different problem, projected onto the present moment like a transparency laid over a photograph.
The junior engineer in the same room has no such curse. They have no patterns to match. Every problem is unprecedented because they have no precedent to reference. And so they do something the expert has forgotten how to do: they look. Actually look. They ask questions that seem naive but are actually fundamental. They challenge assumptions that the expert didn't even realise were assumptions. They wander into corners of the problem space that the expert's mental map had marked as "irrelevant" years ago.
This is not an argument against experience. Experience is invaluable. The senior engineer has seen systems fail in ways the junior cannot imagine. They carry scar tissue that informs judgment. They know, intuitively, where the bodies are buried.
But experience comes bundled with a hidden cost: the inability to see what you've already decided isn't there.
I have watched this happen. I have been both the junior asking the stupid question that turned out to be the only question that mattered, and the senior so locked into a pattern that I spent three days solving the wrong problem with great efficiency. The second experience is more humiliating than the first, because it comes with the realisation that my expertise was not an asset but an obstacle.
The Japanese Zen tradition has a term for what I'm describing: shoshin, or beginner's mind. It refers to an attitude of openness, eagerness, and absence of preconceptions - even when studying at an advanced level. The master approaches each problem as if encountering it for the first time, not because they have forgotten what they know, but because they have learned to hold that knowledge loosely.
In software engineering, we have no equivalent tradition. We valorise expertise without acknowledging its shadow. We build hierarchies based on years of experience without asking whether those years have opened minds or calcified them. We trust the senior engineer's pattern-matching precisely when we should be most suspicious of it - in novel situations where old patterns may not apply.
What would it look like to engineer with beginner's mind?
It would mean approaching each problem with genuine curiosity rather than recognition. It would mean asking "what is this?" before asking "what does this remind me of?" It would mean treating your own expertise as a hypothesis rather than a fact - useful, but not infallible. It would mean creating space for the naive question, the obvious observation, the perspective unburdened by experience.
It would mean, most uncomfortably, acknowledging that sometimes the person who knows the least about a domain sees it most clearly.
I am not suggesting that we discard expertise. I am suggesting that we develop a second skill alongside it: the ability to unknow. To consciously set aside the patterns when the situation demands fresh seeing. To recognise when your experience is helping you and when it is blinding you. This is not easy. The pattern-matching mind is fast and confident. The beginner's mind is slow and uncertain. In a profession that rewards speed and certainty, choosing slowness and uncertainty feels like weakness.
But the bugs that matter - the architectural mistakes that compound over years, the security flaws that sleep until they don't, the design decisions that seem reasonable until they become prisons - these are not caught by fast pattern-matching. They are caught by slow seeing. By the willingness to look at what is actually there, rather than what you expect to be there.
The next time you encounter a problem that feels familiar, pause. Not because the familiar solution is wrong, but because the feeling of familiarity is itself a signal worth examining. Ask yourself: am I seeing this problem, or am I seeing my memory of a different problem? Is my experience illuminating the path, or obscuring the terrain?
The most dangerous engineer in the room is not the one who knows nothing. It is the one who is certain they have seen this before.
Because they will solve the problem they remember with great confidence.
And the problem that actually exists will remain, quietly, unsolved.