In journalism, a reporter writes a story and an editor edits it - reading through the whole piece, catching errors or omissions in writing or reporting, asking questions, and making suggestions at all levels - from how to catch and hold the reader’s interest to how to structure the story to how to smooth out an awkward paragraph or sentence. This is A Good Thing, because a) it’s always good to have someone else go over your work and b) the editor is usually the more experienced writer. In fact, it’s such a good thing that on the occasions when an editor writes a piece, it undergoes something called a “top-edit”, where it’s edited by another editor. This is because it would obviously be crazy to publish something without someone else having read and reviewed it. But in software engineering we do this all the time, and consider it a cornerstone of our hacker-ethos, meritocratic culture.
I think this is bonkers. I’ve noticed that the code of junior engineers is often flawed, sometimes at multiple levels, in ways that are easy to avoid and easy to teach them to avoid. And I’ve noticed that if I delegate a modest-sized project and then walk away until a code review a few weeks later, it will often be the case that the architecture was ill-conceived and the process won’t scale, or has lots of nasty failure modes, and we’ll have to either go with what’s been built or go back and do it properly.
I’ve also noticed that junior engineers will silently bang their heads against things that I can often help them resolve if I just occasionally stop by and ask them how things are going. But instead of just giving them the solution I’ll try to teach them how to ask the right questions and design and run experiments to figure out what’s going on for themselves.
Eventually, I came to think of these editorial and mentoring activities as not ancillary to or a distraction from my job, but the core of my job, and my reasoning comes down to amplification. In journalism, you typically have several reporters funneling their work through one editor, and it seems obvious to me that the aim is to achieve the volume of output of many writers at the quality level of a very experienced writer, while maintaining a consistent voice across the entire organization. The editor isn’t sidelined by not doing her own writing, she’s amplified. This pattern is everywhere - from the fine arts to the sciences to law to most trades I can think of - but I’ve never seen it in software engineering, perhaps because senior engineers tend to enjoy doing their own coding and resist being pulled away from it.
So I now view my role as something like an editor, coordinating and overseeing a team of engineers to amplify my own skill and experience and help them develop theirs. Any time I’m off by myself churning out test cases is time I’m not solving hard problems or helping someone else learn how to solve a hard problem. But for any code I write, I implement top-edits by submitting pull requests for my own contributions - and sure enough, junior engineers will catch me making stupid mistakes. Also, having them examine my code critically keeps them abreast of changes to the codebase and gives them a chance to learn new techniques and ask questions. It’s similar to pair programming, but one of the pair is always me, and I’m always rotating among the team, offering help and feedback wherever I can. The result? The productivity of many engineers, at the quality level of a lead engineer, and a happy team, rapidly growing their skills.