Building Things
A meander on leadership roles and the kinds of contributions we make.
I.
For almost three years, now, I have been more or less steadily—sometimes more, sometimes less!—putting out episodes of New Rustacean. It’s fairly popular. I’ve had really smart people tell me how helpful it was in getting them up to speed with the language. I have had the surprising and slightly weird (if also somewhat gratifying) experience of walking into a room and seeing people respond in recognition of my voice.
I’m grateful for the impact the podcast has had, and as I tell people often: this is far and away the most significant thing I could have done in the Rust ecosystem in the last three years. There are a lot of people better-equipped than I to write top-notch libraries and applications in the ecosystem. People well-equipped for podcasting by dint of already being active in the space, and well-equipped for teaching specifically by dint of background and training? There are a lot fewer of those. I don’t think there is anywhere at all I could have made a bigger dent in the same time for Rust.
And yet.
If I went and applied for a job today, where actual Rust experience was desired, the vast majority of my show’s listeners would have substantially more to show than me. A command line tool here, a little experiment there. My one real project has been on hold almost since I started it. Another project, my original inspiration for learning Rust at all, I’ve never even started. My actual lines of Rust code written in the last three years top out somewhere under 3,000. It’s a pittance. As well as I know the language’s ideas, and indeed as well as I can explain them… I actually haven’t gotten to build much of anything with it.
II.
The last few months at work, I’ve spent a lot of my time—and an increasingly large proportion of it—on mentoring, code reviews, and leading the team and effort I’m on. This is genuinely wonderful in a lot of ways. I love teaching, and it’s a pleasure to help shape the overall direction of a project and a codebase.1 In many ways, I’m right in line with the goals I set explicitly with my manager at the beginning of the year.
That’s really good, and really important. I recently saw someone tweet the pithy remark that the definition of a senior engineer is that they are mentoring a more junior engineer. I don’t think that’s quite right—there is a lot of room for really outstanding technical contributors who don’t have the gift of teaching, but whose technical chops mean they genuinely are senior people on the team.2 But the reasonable insight under the hyperbole is that enabling others can often be far more effective than merely doing work yourself.
And yet.
Over the last several months, the amount of code I have written myself has dropped substantially. Not to nothing, of course; I’m still doing the actual work of designing and implementing pieces of the application I work on a majority of the time. But I’m not sure how much more than 50% of my time it is on any given week at this point. As much as I’ve enjoyed helping drive this particular project forward,3 I haven’t actually gotten to build as much during this phase of it.
III.
These two things have a great deal in common, for all their superficial differences. Both are places where my most valuable contributions are not what I can build myself, but what I can enable others to build.
Thousands and thousands of people have listened to New Rustacean. For some non-trivial number of them, the podcast was an important part of their wrapping their heads around the language. I know this because they tell me, in emails and conversations and tweets that are genuinely my favorite parts of doing the show! I have done far, far more with the podcast than I possibly could have by building another library in Rust.
Similarly, albeit on a much smaller scale, my role in my team at Olo matters. I’ve been able to help set the overall technical direction of a number of our front-end initiatives at the company in important ways. I’ve been able to help more junior developers ramp up their skills. I have done far more in this kind of role than I could possibly have done by just quietly shipping features.
And yet.
Being a “force multiplier” (what a terrible phrase!) isn’t always what it’s cracked up to be. It can be both worth it and also profoundly frustrating and boring at times. I was drawn to software in no small part because of the joy of being able to make things—to start with nothing but an idea or a sketch and a few hours later have something people can interact with, that solves a problem for them. I still love that side of it, and it’s clear to me if nothing else that (for the foreseeable future, anyway) I have no desire whatsoever to go into management roles, “force multiplier” or not.
There’s a real trick here, because it’s not that I’m not building things in these roles. It’s just that building a team or a community is not quite the same thing—it does not scratch the same itch—as building a really elegant user interface component with an elegant and communicative animation. They’re both good; and they’re very, very different from each other.
I separate those on purpose: a project and a codebase are related, but they’re far from identical. A project can succeed—at least in the short term—with a terrible codebase; an excellent codebase is no guarantee of project success. Getting them aligned is rare, difficult, and rewarding.↩
This seems like a typical overcorrection: against the idea that teaching is unimportant, it now comes into vogue to say that teaching is the most important. Imagine if we simply noted that teaching is some people’s gift and vocation, and not others; and that we can complement one another’s strengths by sharing our own—that it is not a zero-sum game but one in which we are like hands and feet and elbows and ears, each one needing the other, none able to do without the others.↩
much of the time anyway; the burnout I’m experiencing is related to some of the dynamics of this particular project↩