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â©