Name every teaching surface you already operate — README and docs, code review and onboarding, blog or newsletter, talks, any courses or guides — and diagnose, honestly, where each is producing compounding career or revenue value and where it isn't. Stop operating from "teaching is something I might do later"; start operating from "teaching is what I'm already doing at scale, and now I'll do it deliberately."
This is git blame plus a post-incident review run on your own output. The audit table is a service inventory: every teaching surface is a service you operate, most of them unowned, unmonitored, and running whatever code was deployed years ago. You don't fix an unowned service by writing more unowned services. You fix it by naming an owner — and the owner is you.
Here is the thing nobody tells you about being a working engineer: you have been teaching every day for years. You did not call it teaching. You called it code review, onboarding …
You can't operationalize what hasn't been named as a gap. Most engineers carry substantial teaching surface area they have never once audited for effect. The open-source README re…
Approach: Essential
Approach: Essential
Approach: Important
Approach: Important
1. Produce TEACHINGSURFACEAUDIT.md — one row per teaching surface you operate (package docs, code review, onboarding docs, blog/newsletter, talks, courses/guides, video if any), w…
7 lessons. Read in order; spiral back when you need to. By the end you'll have used the core ideas twice — once on the abstract, once on something you'll meet at work next week.