The More You Know, the Harder It Gets to Teach: Breaking the Senior Developer's Communication Trap

There's a moment most junior developers know all too well. You've hit a wall, you finally work up the nerve to ask the senior engineer sitting three desks over, and they walk up, stare at your screen for about four seconds, type something, and say "yeah, it's just doing this" — as if that explains anything at all. They're not being dismissive. They genuinely think they explained it.

This is one of the quieter dysfunction patterns inside engineering teams, and it's way more common than anyone wants to admit. The people with the most knowledge are often the worst at transferring it. That's not a coincidence. It's actually kind of inevitable — unless you know what's causing it and deliberately work against it.

What Cognitive Science Has to Say About This

In 1990, a Stanford grad student named Elizabeth Newton ran a now-famous experiment. She had people tap out the rhythm of a well-known song on a table while others tried to guess it. The tappers predicted listeners would identify the song about 50% of the time. The actual success rate? Around 2.5%.

The tappers couldn't hear what the listeners heard — silence and random knocking. In their heads, the melody was playing loud and clear. They couldn't un-hear it.

This is what psychologists call the curse of knowledge, and it maps almost perfectly onto what happens when a senior developer tries to explain something foundational. Once you truly understand how memory allocation works, or why async/await behaves the way it does, you literally cannot remember what it felt like not to understand it. The mental model is so baked in that you skip over the parts that feel obvious — which, to a junior dev, are the exact parts that aren't obvious at all.

Mid-level developers, interestingly, often make better teachers. They're close enough to the confusion that they still remember it. They haven't fully automated the knowledge yet, so they can still narrate it.

The Automation Problem

Here's another way to think about it. When you first learned to drive, you were consciously managing every single input — mirrors, pedals, turn signals, road position. Now you probably drive home from work and barely remember the trip. That's because your brain converted a high-effort conscious process into an automatic one.

Experts do the same thing with technical knowledge. A senior engineer reading a stack trace isn't consciously walking through each line — they're pattern-matching against thousands of hours of similar errors. It feels like intuition. And intuition is almost impossible to teach directly because it doesn't have steps anymore.

When someone asks "how did you know it was a race condition?" the honest answer is often "I just... knew." That's not helpful. But it's real.

So What Actually Helps?

Force the Narration Out Loud

One of the most effective techniques is something that feels a little awkward at first: think-alouds. When a senior dev is debugging or building something, they narrate every step out loud — not just what they're doing, but why. "I'm checking the logs first because I want to rule out a network issue before I look at the application layer."

This sounds simple, but it does something important. It forces the expert to surface the reasoning that normally runs silently in the background. Junior devs don't just learn what to do — they learn the decision-making framework behind it.

Write Documentation Like You're Talking to Past-You

A lot of internal documentation reads like it was written by someone who already knew everything. It's full of assumed context. A better approach: write for the version of yourself that existed before you learned this thing.

That means defining terms you'd normally skip. It means explaining why something works, not just how to do it. It means including the wrong approaches you tried before landing on the right one — because that failure path is actually incredibly valuable to someone who's about to make the same mistakes.

At CHTree, we've seen developers build whole documentation habits around this idea, and the teams that do it consistently tend to onboard new hires dramatically faster.

Create "Confusion Checkpoints"

In mentorship sessions, it's easy to mistake silence for understanding. Junior devs often don't speak up because they don't even know what they don't know yet. A simple fix is building in deliberate checkpoints — not "does that make sense?" (which almost always gets a yes regardless), but more specific prompts like "tell me what you'd do next" or "what's still fuzzy here?"

This shifts the burden of proof. Instead of assuming comprehension, you're actively testing it — and doing it in a way that doesn't make the junior dev feel like they're failing a quiz.

Teach by Analogy, Then Validate the Analogy

Analogies are powerful, but they're also dangerous. A good analogy gets someone 80% of the way to understanding something — and then the remaining 20% is where the analogy breaks down, and if you don't address that explicitly, you've accidentally built a misunderstanding.

So when you explain that "async functions are like placing an order at a restaurant — you don't stand at the counter waiting, you sit down and the food comes to you" — great, useful framing. But then you also need to say "here's where this comparison stops working" and walk through the edge cases the analogy can't capture.

The Bigger Point Nobody Wants to Say

There's a culture thing underneath all of this that's worth naming directly. In a lot of engineering teams, the ability to explain something clearly is treated as a soft skill — nice to have, but not really what separates the good engineers from the great ones. Technical depth is what gets celebrated.

But that framing is expensive. When senior engineers can't transfer knowledge effectively, you get teams where institutional knowledge lives in one person's head. You get junior devs who feel like they're constantly in the way. You get slower onboarding, more repeated mistakes, and a ceiling on how fast the whole team can grow.

The engineers who can do hard things and explain them? Those are the ones who actually multiply a team's output. That's not a soft skill. That's leverage.

Growing Together Means Communicating Across the Gap

The curse of knowledge isn't a character flaw. It's a predictable side effect of getting really good at something. But predictable problems have solutions, and this one mostly comes down to deliberate practice — slowing down, narrating your thinking, writing for confusion, and building habits that keep you connected to what it felt like to not know the thing you now know cold.

Growing as a developer isn't just about learning harder things. Sometimes it's about relearning how to explain the easy ones.