Teaching

Mentoring others. Leaving breadcrumbs.

The Obligation

You didn't learn alone.

Someone answered your questions. Someone reviewed your code. Someone wrote the documentation you read. Someone gave the talk that shifted your thinking. Someone wrote the book that changed how you work.

The chain of knowledge passes from engineer to engineer. You received. Now you give.

This isn't optional. It's how the profession works. The veterans who came before you invested in passing on what they learned. You have the same obligation to those who come after. (Learn From Those Who Came Before carries the receiving half of this chain.)

Compression and decompression

Here is the model I use for why experts are hard to learn from. I am still testing it, but it has earned its keep every time I have taught.

Expertise compresses. Repeat something enough times and the explicit steps collapse into one automatic move; the expert stops perceiving fifty decisions and sees one obvious action. That compression is what makes experts fast. In this model, it is also what makes them hard to learn from, because the steps a beginner needs have become invisible to the person performing them.

Teaching is the reverse operation. Expertise is the compression of knowledge. Teaching is the ability to decompress it without distorting it. The teacher holds two models at once: how the thing works once understood, and what the world looked like before that understanding existed.

Four people look at the same topic:

• The novice sees a wall.
• The recent learner remembers assembling the bricks.
• The expert sees the building.
• The teacher can see all three.

The warning words that mark compressed knowledge: just, simply, obviously, clearly. "Just add an index." "Simply inject the dependency." Each one skips steps the speaker no longer perceives. The word "just" is often where the missing curriculum begins. When you catch one in your own explanation, ask the question I now ask of every instructional sentence I write: what knowledge have I compressed that this reader has not yet acquired?

The limit: decompression can become over-explanation. The goal is not to enumerate every detail. It is to identify which intermediate steps this learner, at this level, actually needs.

Being one step ahead

You don't have to be an expert to teach. You just have to be one step ahead.

The thing you learned last month is exactly what someone needs to learn today. Your recent struggle is fresh; you remember the confusion, the breakthrough, the path through. In compression terms, your knowledge is not yet compressed: the steps are still explicit, which is exactly what the next learner needs.

Don't wait until you're an expert. By then, you'll have forgotten what it was like to not know. Teach from the edge of your knowledge.

Share your learning journey. "Here's what I just figured out" is valuable. Others are on the same path.

Leaving breadcrumbs

Every artifact you create is a message to the future. Make it useful.

Write commit messages for the person doing git blame: they are trying to understand why this code exists, so explain intent, not just the change. Write comments that explain why, not what; the code already shows what. Document the non-obvious, and warn about the gotchas. And when a decision was significant, record it where "why is it like this?" can find it: the ADR template exists for exactly that question.

The test for any of it: could someone new understand this without talking to you? If no, it's not documentation; it's notes.

The practitioner-teacher

The phrase "those who can't do, teach" kept me from claiming the word teacher for years. Then I looked across the domains I have worked in: aircraft maintenance, medical instruction, recruiting, leadership, software. The domains kept changing. The function underneath did not: enter a system, learn its shape, do enough real work to meet reality, notice where people get stuck, name what was implicit, and hand the model to the next person.

Three roles, worth distinguishing because they ask different things of you:

• A trainer helps you do the thing.
• A teacher helps you understand the thing.
• A mentor helps you become someone who can navigate the thing without them.

The function needs both halves to stay honest. Teaching without current contact with practice drifts into abstraction. Practice without reflection produces expertise that is hard to transfer. The version of the job I aim at now: learn systems well enough to make other people better inside them.

The chain continues

Someone helped you. Now you help someone else. They'll help someone after.

This is how the profession renews itself. This is how knowledge survives the individuals who discover it. This is how each generation stands on the shoulders of the last.

Be the steel that sharpens steel. Pass on what you've learned. Leave the codebase better than you found it. Leave the team stronger than you found it. Leave breadcrumbs for those who follow.

The chain continues through you.

Teach what you know. Mentor those behind you. Leave breadcrumbs everywhere. The knowledge you share is your legacy.