On Mentorship in an Industry That Moves Too Fast

Thesis

Mentor the slow layer: judgment, taste, and how to show up. Tools turn over. The ability to read a system, weigh a tradeoff, and recover from being wrong in public compounds across every stack a person will ever touch. Framework tourism looks like mentorship. It is not.

Context

A contributor joined me on the mystic-bytes reading pipeline: Node scripts, Postgres manifests, vision rename passes, the usual glue. Week two they asked the honest question. Should they learn React Server Components, or go deep on the import scripts first?

The honest answer: the import scripts will still be here in six months. RSC may not be how we ship the site by then. The scripts are also the wrong thing to worship. The durable lesson is how to trace data through a pipeline, write a reversible change, and document the contract for the next person.

I have watched mentorship fail when it became toolchain recall. The senior engineer performs expertise. The mentee learns where the buttons are. They do not learn what to do when the buttons move. One senior operator, no formal curriculum, a stack that will change before the first solo PR merges: that is the usual constraint. Pretending you can apprentice someone into a stable platform is a 2012 fantasy.

Teaching-as-debugging is the companion problem: you find the holes in your own model. This essay is about what you transfer on purpose so the other person still has a career after the framework dies.

Mechanism

Two layers of skill, decaying at different rates.

The fast layer is syntax, APIs, framework idioms. High decay. Necessary for shipping this quarter. You still pair on it. You name it as perishable while you do.

The slow layer is systems reading, risk assessment, communication, epistemic humility. Low decay. This is what decides whether the fast layer is applied wisely. Andy Grove framed the manager’s job as output through others. In technical mentorship the multiplier is judgment transferred, not keystrokes copied.¹

The Dreyfus model of skill acquisition — novice to expert — shows that experts rely on pattern recognition across cases, not rules memorized in isolation. You cannot Dreyfus someone by handing them docs. You give them progressively ambiguous problems and stay present while they misread one safely. Hovering forever prevents the pattern from forming. Abandoning them on day three prevents it too.²

What I try to put on the slow layer, out loud, so it is not folklore:

Read before write. Map inputs, outputs, owners, and failure modes before opening the editor. The first hour of a ticket is reconnaissance.

Name the tradeoff. Every choice has a cost. Say it in the PR. Silence is how teams inherit decisions they cannot explain.

Write for the absent maintainer. Comments and commit messages are mentorship letters. The next reader may be the mentee after you have rotated off.

Disagree without cruelty. Call a bad idea bad. Do not call a person stupid. The industry already has enough of the second habit.

Leave on time. Bandwidth is finite. Ending the meeting is senior behavior, not a personality quirk.

Frameworks still matter as coursework, not identity. I pair on the actual stack. I also say, explicitly, that this is the fast layer. When Next.js or the vision CLI changes, the habit of tracing slugs through manifests remains.

On Nightbind I mentored a contributor through a payment edge-case fix by drawing the state diagram together rather than dictating the patch. They shipped the fix. They kept the diagram habit when the payment provider changed fields three months later. The diagram was the transfer. The patch was the homework.

Mentorship scales poorly. Design for residue. Office hours, review culture, incident postmortems assigned as reading, shadowing on one real incident: these leave artifacts. One-to-one heroics do not scale. Documented judgment does. If the only copy of the lesson lives in your calendar, you have not mentored. You have rented out an hour.

Tradeoffs

Depth on the current stack versus breadth on principles. Shipping requires stack depth. Careers require principles. A good mentorship quarter does both: one real feature on the current tools, one explicit retro on what would survive a rewrite. All-principles mentorship produces people who cannot merge. All-stack mentorship produces people who panic at the next changelog.

Time now versus autonomy later. Hovering prevents mistakes. It also prevents learning. The goal is a shorter hover each week, not permanent pairing. If you still type their code in month three, you have a staffing problem wearing a teaching costume.

When industry speed helps. Fast churn forces beginners to learn how to learn — docs, source, debugging — instead of settling into one vendor’s gospel. Frame the chaos as practice. Do not pretend the chaos is betrayal. The field moved. That is the job.

When mentorship is not enough. Toxic intake, no psychological safety, no time budget: no mentor fixes a broken system. Environment eats individual coaching. See the burnout essay. You cannot apprentice someone out of an unsafe rotation.

Close

Teach the next person what you would need if every framework disappeared tonight: how to read the system, name the risk, write the note, and say “I do not know yet” without shame. The tools will rotate. That posture is what makes them worth hiring after the rotation.

One senior. No curriculum. Teach what survives. The rest is homework they can look up when the buttons move.

— JV · Dark Heart Labs.

References

Andrew S. Grove, High Output Management (Vintage, 1983). Leverage through developing others — the management frame that applies to formal leads and to senior ICs who mentor without the title. ↩
Stuart E. Dreyfus and Hubert L. Dreyfus, “A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition,” UC Berkeley ORC, 1980. Novices follow rules; experts recognize patterns. Mentorship that only transfers rules never graduates the person. ↩