You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 5: One-on-One Teaching — Code Review, Pairing, Mentoring #

M0 told you that you have been teaching every day for years without calling it teaching. This module is where that observation gets instrumented, and the audit is the brutal part. When you categorize your last twenty code review comments — parking ticket / style nit / teaching moment / genuine bug-catch — most engineers find their teaching-moment percentage lands somewhere between 10% and 25%, and most feel slightly defensive about it. The defensive reaction is wrong. The audit is not an indictment; it is a data point. Code review is mostly parking tickets in production engineering, because most diffs are routine and most comments are appropriately routine. The point is not that 100% should be teaching. The point is: when an opportunity does present itself — when the diff has a real principle inside it — do you spend the extra ninety seconds to make the comment teach, or do you say "use let here" and move on?

Ninety seconds. That is the difference between a comment that resolves a diff and a comment that compounds across someone's career. The seniors who are good at this have noticed something the rest haven't: those ninety-second comments are how a team's culture actually gets built. The senior who consistently leaves teaching comments produces juniors who write better code on their second PR than their first; the senior who can't be bothered produces juniors who never level up and a team that has to re-litigate the same review arguments quarterly.

This effect is real, it is measurable, and it is almost entirely under your control — which makes it one of the cheapest forms of leverage available to a working engineer who never wants to be a manager.

A specific honest observation about pairing: most pairing sessions are bad teaching. The senior takes the keyboard "just to show," the junior watches, the junior nods, the junior retains nothing. The strong-style protocol — for an idea to go from your head into the computer, it must go through someone else's hands — is uncomfortable the first time you try it. You will be slow. You will have to verbalize things you have done silently for a decade. The junior will fumble. This is the point. The discomfort is the teaching, and the fumbling is the retrieval practice M1 told you about, happening live.

I want to flag the hardest part of this module, which the books soften and I won't: feedback for adults is psychologically expensive. Crucial Conversations gives you vocabulary, but vocabulary does not reduce the cost. You will avoid hard conversations for weeks past when they should have happened. You will rehearse them in the shower. You will deliver them and feel terrible afterward, even when they go well. This is not failure; it is the cost of taking the relationship seriously. Engineers who never feel the cost have either become the kind of senior whose feedback nobody takes seriously, or they are delivering it badly and not noticing. The cost cannot be eliminated, only paid deliberately.

And the "How we do code review here" document will feel pointless until you are halfway through writing it, at which point it will start surfacing implicit team rules nobody had ever stated. That surfacing is the value. The published document is a side effect.

Conclusion #

Most of the teaching senior engineers do is one-on-one and uncounted. The work of this module is to make it counted — with intention, with protocols where instinct fails, and with the willingness to pay the psychological cost of real feedback. The compounding is significant and almost entirely invisible to anyone but the recipients, which is exactly why it is undersupplied and exactly why it is worth doing.

Predictions #

  • Your teaching-moment percentage in code review will roughly double within a month of the audit. It will not triple; the realistic ceiling for routine review work is around 40-50%, and that is plenty.
  • You will run one strong-style pairing session, find it uncomfortable, and not run a second one for a while. Then you will come back to it, because silent watching will have started to feel wasteful.
  • The "How we do code review here" document will be useful to your team for about eighteen months, after which it will need a rewrite. Normal; a stale guide is worse than no guide.
  • You will have at least one hard feedback conversation in the next ninety days that you would otherwise have postponed. It will go better than you feared, and you will still feel drained afterward. Both are normal.
  • Within six months, one or two of your teaching investments will produce an outsized result — a junior who is now a strong mid, a peer who started leaving teaching comments themselves. You will not have predicted which ones. Compound interest is unpredictable in detail, predictable in aggregate.
  • Apprenticeship Patterns will land surprisingly well despite being older than some of the engineers it describes. The examples are dated; the patterns are not.