Hello, everybody!
So, a brief content warning before I get started: I talk about burnout and stress a lot in this talk, because I’ve spent most of the last couple years working on getting better about both of those things. Right now, things are actually going really well both for me and my team. We’re OK! If you’ve been dealing with these issues yourself, my hope is that you’ll be able to relate without getting bummed out, but if you want to take a pass on hearing about other people’s stress because it triggers your own, I won’t be offended.
That said, hi! I’m Forrest Lehwalder Norvell, and I’m the team lead for the npm command-line interface. If you don’t know what that is, the short version that one of the Bens here came up with yesterday is that npm is a cupboard on the internet where developers cram all the crap that they or somebody else might want to use again someday. The important thing is that it’s a very popular open-source product, and it has a large and enthusiastic community. I have now finished the technical portion of my talk. Whew!
I joined npm, Incorporated, the company that Isaac Schlueter, Laurie Voss, and Rod Boothby started to support and monetize npm, about a year and a half ago. I was fortunate enough to have a bunch of opportunities at the time, and I chose to go to npm because I felt it was my best chance to support the JavaScript community. The JavaScript community has been very good to me, and I wanted to pay that back. I feel good about my choice.
If this talk has a thesis, it's that acting in your own best interests with an eye on the long term will more often than not lead you to behaving ethically in the short term. There doesn't have to be a conflict between doing what's best for you and what's right. This is something that can seem obvious, but it's nice to say it out loud once in a while.
Y’all are getting a special talk from me today. In part because I think this is the right talk for this conference and this audience, and in part it’s because of where we are. I’m a native of Cascadia, having been born in Portland and having family roots in Montana, and the Tri-Cities are located midway between those two places. In a lot of ways, this place incorporates a lot of what I like best about both of them. That bridging of worlds makes it a natural place for me to bridge times as well, and talk about something I’ve been thinking through for a while now, which is how I became the kind of person who really cares about open source communities and who wants to support them.
Another quick disclaimer: I’ve tried to avoid the trap of turning talks into lists of commandments. This is my story, and the strategies I talk about in this talk are what have worked for me and my team at npm. Maybe they’ll work for you too. I hope so. But you are the boss of you, not me, and I hope this doesn’t come across as too preachy.
In 1992, I transferred to the University of Montana, about 340 miles east of here in Missoula, Montana. This is part of the reason this conference, in this place, has such resonance for me – the Tri-Cities were literally part of my transition between my home in Portland and school, and I’ve lost track of how many times I’ve been through here. I love Montana and the intermountain west – its beauty, the seasons, the vast spaces and total emptiness.
My new friends in Missoula, many of whom were native Montanans, were maybe not so keen on that last part. Something I got used to hearing were their frequent complaints that there was nothing to do. I felt this too, but part of the reason I was a transfer student was that I’d gotten fed up with how many of my friends at my previous school kept talking about how much they hated downstate Illinois, yet never did anything about it. I’d done something about it (by getting the hell out of Galesburg), and by so doing had taught myself that that was a thing I could do.
The summer of ’92, I’d started going to raves in Portland. The rave scene blew my head wide open. The emphasis on just getting inside yourself with a bunch of likeminded people – a communal space for solitary experiences – tapped into something I hadn’t really known I was missing before then. I’d come home from parties with my ears buzzing, the beat pulsing inside my head for a couple days after a party. I’d started buying techno and UK hardcore and house (or trying to – it was really hard to find back then) and had been reading descriptions on USENET of totally wild parties involving multiple locations, elaborate preparations, and efforts to make each party a unique experience.
So when my new friends were complaining about having nothing to do, it seemed pretty natural to turn my new interest in raves into a way to solve their problems with boredom. If this were a movie, now would be time for a montage sequence, because it took a while before I was in a position to actually put that impulse into action. In fact, it took two things: finding a crew of people I could work with to make things happen, and learning the bare minimum of skills to be a not totally terrible DJ.
That took until the fall of 1994. In the intervening time, I’d gotten my first experiences as a DJ, thanks to to a house DJ who’d pretty much singlehandedly brought dance culture to Missoula.
As importantly, the internet had produced an amazingly comprehensive set of resources for would-be rave promoters: how to run an event, how to create a safe space for parties, mailing lists to contact other ravers and promoters in my region, how to engage with the police when they show up at an illegal house party in such a way that nobody goes to jail (side note: Missoula cops were always mystified by the fact that nobody seemed to be drinking but were still really friendly – apparently they weren’t watching Beverly Hills 90210).
So this is what I used when I worked with my crew of four to throw our first party. We set a date, rented the Elks Lodge (as well as a sound system and lights), and drew straws to figure out who would play first.
And then we had to promote the goddamned thing.
I went door to door in every dorm on the University of Montana campus, knocking on dorm room doors, handing out flyers, and explaining to people what we were doing and why it was going to cost the completely unreasonable sum of five dollars to come to our dance party. I’m actually kind of an introvert, so I was kind of a mess by the time I was done. But I did it, and in the process of convincing some particularly ornery and weird skate punks that I wasn’t selling Amway, ended up making friendships that lasted the rest of my time in Missoula and beyond. It was a pretty hardcore way to learn about the importance of putting myself out there, one on one, in front of a lot of people. A pretty weird sales job, in a lot of ways.
The night of the first party was excruciating, because I hadn’t yet learned about Party Standard Time, and people didn’t really start showing up until an hour or so in. And when people started showing up, it was a total circus. College students are not only really quick to get bored, but most of them, at least in Missoula, are pretty broke most of the time. Five bucks was not a trivial sum of money to drop on an unknown quantity like a rave in Missoula. My girlfriend and I were working the door, and we were more interested in having people show up and have a good time than making money, so we basically told people to get creative: do some interpretive dance in lieu of currency, draw us two-for-one coupons, tell us a good joke. From this I learned a couple things: most people are too self-conscious to make asses out of themselves in public, but it doesn’t take much to make people feel like they’re part of creating the vibe.
What really drove this home for me was what happened when we shut the party down at 2 (I mean, this was at the Elks Club – we weren’t able to do all-night parties until we moved to the American Legion Hall (Montana!)): after the sound system was turned off and the lights were turned on, there were a good handful of people who had stuck around to help us tear down and clean up.
So, this is where we start getting to where my past life and my current life intersect: people just show up. Without us asking, people show up. Often, they’ll take on the areas where you need the most help but just don’t have the resources to deal. All we had to do was show people that this was something we were doing for them as much as us, and they showed up.
I see this happen all the time with npm. This slide shows contributions on npm’s issue tracker by Kenan Yildrim. Nobody who works for npm, Inc. has ever met Kenan, but he’s been handling a huge amount of npm’s front-line support, pretty much on a daily basis, for a couple years now. He only answers questions he can answer confidently, but even so, if you look, you can see that he’s commented on over eleven hundred issues. This blows my mind. npm owes Kenan a debt we can never repay, and I can only hope that whatever motivates him to do all this work for the project is rewarding him adequately. Kenan isn’t an isolated example. Open source is magic this way, and I can’t put into words how much I appreciate the people who have just showed up.
That group of people in Missoula also taught me another important lesson that is all too applicable to open source software: people who just show up often have their own ideas. This group of people ended up becoming another promotion team, the Badlander Sound System, and they had their own ideas about where and how they wanted to throw parties, which involved things like doing break-ins (to abandoned boxcars and disused Quonset huts – again, I love Montana). This made me super uncomfortable, because one of my main theories was that this was all going to work better if we kept the police on our side. It took me a while to get over myself and realize that we agreed about the important things – that people needed to be (and feel) safe, that the promoters and partiers were in it together, and that having fun was more important than being in charge (I mean, they went along with my desire to have DJs draw straws to choose play order, and in retrospect that’s awesome).
This is a big part of open source as well. Left to their own devices, most open source contributors will scratch their own itches, or put another way, will address their own needs. This is a really important part of how open source works, and I've found that it's tricky to balance the needs of individual contributors with the needs of the project as a whole.
Here I have to sort of change the subject for a minute and talk about product management. If you have experience with product management, you know it comes down to two things a lot of the time: asking people, “what problem are you trying to solve?” and saying no a lot. It’s important for products to tell a simple and straightforward story to their users, and that mostly means the people managing the project need control and focus over it.
The thing about open source products is that if you behave that way, you run the risk of people either deciding your product isn’t for them and not using it, or they decide to meet their own needs and fork it. So yeah, you still need to ask people what problems they’re trying to solve (and sometimes you discover that while they’re trying to solve problem Y, what they want to solve was originally the more fundamental problem X, which is such a common situation that it has its own web site), but the reason I, as an open source product manager, do that is so that I can tease the common threads out of a bunch of issues and work with the problem-havers to work out a single solution that meets many needs at the same time. Most of the time, finding that problem statement is the hardest part of the work – the code is relatively easy once we know what we're doing and why.
So throughout that fall and winter we kept throwing parties, and more and more people got involved (there were probably 8 to 10 DJs and twice as many people as that helping out, in three or four loose groupings). It wasn’t unusual for us to have 400 to 600 people show up to our actual raves, and pretty much every party was completely different (I’ve told a bunch of you about the Halloween party involving a dude in a hockey mask with a chainsaw, and if you haven’t heard it you should ask me about it – it’s a great story).
We all did basically everything – I was at different points a sound guy, a flyer designer, a promoter (I was never able to get away entirely from handing out flyers and hitting people up, even though I never got completely comfortable with it), a DJ, a janitor, a security person, a counselor, and more or less a doll for people on lots of drugs. My role was changing, though, mostly because I was trying to concentrate on becoming a better DJ (I was way better at figuring out how to get people to dance to really improbable combinations of tracks than I was at the mechanics of DJing), and also because one of the awesome things about a scene that grows itself is that even though my little crew had started a bunch of things, the people who had joined in later quite frequently had much better ideas than I did.
For instance, that boxcar break-in I mentioned earlier: I was totally against it because I was convinced we were going to get in trouble (and I’m pretty sure that party was being watched by at least one carload of plainclothes policemen, and I will always wonder why they didn’t bust us), but something about playing 8 remixes of Johnny Jungle’s “Johnny” in a row in this weird constrained space out in the middle of nowhere made for a really intimate and special time. I will remember that party for my entire life.
Something that I had to relearn recently that this could have taught me if I’d been paying attention is that a big part of leadership is letting go. We have these ideas in our heads about how things should be done, but more often than not what we actually care about is what should be done. If somebody does something differently, that’s not bad, it’s just different, and often it will be better. Getting out of the way and letting my friends throw parties their way let me have experiences I would have been poorer for not having and also let them take things further and into places I couldn’t have. They were better at this stuff than I was, and by not caring who got the credit, everything was better.
There are a couple of things that were happening at this time that I think I can tie into my work on npm without torturing too many analogies. The first is that we learned after a while that the best time to plan the next party was the morning after the previous one. Many of my friends’ serotonin levels would be curiously low, and we’d typically be exhausted from cleaning up the venue, and that was a great way of keeping us from letting our plans get away from us. I’m going to use this to turn to something near and dear to me, and returns us to the topic of Strand McCutchen’s tweet at the beginning of this talk: burnout.
Isaac and Laurie more or less wrote me a blank check when it came to my responsibilities at npm (I had a very vague idea of what I was going to be doing when I agreed to take the job), and I ran with it. I love my job as much as it’s possible to love a job. At the same time, sometimes it feels like it’s taken a few years off my life.
npm’s community is vast. These days I’m more surprised when somebody hasn’t heard of npm than when they have. People do an astonishing array of things with it. It is so much bigger than us – the maintainers, the company, even the people who publish packages to it. It can be really overwhelming. The thing about being overwhelmed is it’s one of the main things that leads to burnout, and that can prolong and worsen burnout once you’ve started feeling it. And as much as I’d like to believe that being aware of its ability to be overwhelming will help me manage that, that’s not how it works. What it can do is alert me that I need to change how I’m doing things and come up with a strategy for dealing with things.
Here’s a picture of the npm issue tracker from a few days ago. That’s over 1,240 open issues, about evenly split into support tickets, feature requests, and straight-up bugs. That’s a lot! A trap I fell into a lot for the first year or so I was at npm was basically succumbing to issue-tracker-driven development: the easiest mistake in the world to make, that of confusing urgency and big scary numbers with actual importance. Doing that left me feeling perpetually behind, and caused me to be twitchy and anxious, feelings which are really infectious and dangerous when they get loose in teams.
What all those issues represent to me is responsibility: responsibility to npm to stay on top of everything, and responsibility to the community to honor their contributions and keep them in the loop.
After doing this for a while, I started to notice this really weird thing: I could feel the way I engaged with the world changing in response to all of the pressure I was dealing with in keeping up with GitHub, Twitter, and IRC. It felt like being brainwashed, but in a really weird, organic, self-directed way. I’ll get to some of the other ways this manifested in a bit, but for now I’ll just say that it’s scary and discomfiting to feel your personality changing due to your job.
What’s especially scary is when you look at this Wikipedia page. Jacob Kaplan-Moss used this page in his excellent Open Source & Feelings talk about why he left the Django project, and reading it was incredibly sobering to me, because I saw so much of it in myself. I’ve been through most of the stages on this page (which I highly recommend that you all read, and think about) except for physical collapse, and many of them since coming to npm. In particular, there’s a section on “revision of values” that says, “While falling into a state of denial of basic physical needs, perceptions and value systems change. Work consumes all energy, leaving none for friends and hobbies. The job is the new value system and people start to become emotionally blunt.” Hiiii!
I love my job, but it can destroy me if I let it, and it’s very important – to me, the project, the entire npm community – that I not let that happen. I don’t think it’s an exaggeration to say that my most important project this year has been figuring out how to make my team’s workload sustainable and to figure out how to keep burnout at bay. The good news is that we’re doing pretty OK now, but getting there has taken a lot of work and kinda put a bunch of us through the wringer.
(slide saying "LIFE/WORK BALANCE IS NOT OPTIONAL")
I want all of you to look at this slide and really let it sink in. npm’s been devoted to the idea of work/life balance since day 1, and it took me a while to realize that it’s more than just a recognition that all of us have been around the block a few times and are past the point in our lives where we feel like killing ourselves for work might conceivably be a good idea. It’s more about recognizing our limitations as living beings. A thing I’ve belatedly figured out is that it doesn’t matter how passionate I am about something, if I keep doing it for too long, I’m going to end up getting progressively more stupid and useless. If I’m going to be productive and effective, I have to turn off the computer, sleep, hang out with my dog, read an Ann Leckie novel – just get out of my work context and give myself a chance to regenerate some energy.
When we were planning our parties while we were exhausted and coming down off however many tabs of E we’d done the night before, we were effectively harnessing our own exhaustion to enforce a kind of work/life balance. Being immersed in the internet 24/7 makes it so easy for me to screw myself and put myself in the red. GitHub, as the only social network that matters to open source nerds like me, makes it incredibly easy to just fall down a collaborative rabbit hole and not notice how far overextended I’ve gotten.
This is all a lot to take on, so let’s take a sec and just breathe for a minute. It doesn’t really matter how you do it, but learning how to pay attention to my own body and breath has been probably my most important tactical skill for avoiding burnout. I’ll get back to this in a minute, but an awful lot of my life these days is taking a few deep breaths and consciously letting go of whatever’s in the forefront of my brain.
OK.
This leads to one of the most crucial lessons that I learned from my promotion days that has stayed with me ever since. As many of you probably know, the original credo of ravers was PLUR – Peace, Love, Unity, and Respect. A lot of what had appealed to me about the rave scene from the outset was the positivity and inclusiveness of the scene. It would be lying to say that none of that was chemically mediated, but enough of it bled into real life to make a drug-free anarchist like me really want to preserve that spirit.
At the same time, I was taking all of what I was reading on the web at face value, and what I didn’t learn until I moved to San Francisco a year later was that all of that stuff was heavily mediated by the PLUR spirit and as such they didn’t include the fact that the scenes that were producing these how-to guides were full of all kinds of drama and infighting and bad vibes. I didn’t see any of that, and here’s the important part: I thought it didn’t exist.
I spent a lot of time and effort trying to live up to the egalitarian, inclusive standards of what I was reading on the internet, without knowing that it was describing an ideal very far from the reality (if I sound a little edgy here, it’s because dealing with the reality of San Francisco’s rave scene in fact burnt me out as hard as any tech job I’ve had, and it took me close to 20 years to get over it). What we built as a group was actually better in most significant ways than the big city rave scenes: we didn’t have a lot of cliques, we were more interested in what people brought to the scene than how important they were, and with a few hilariously disastrous exceptions (like the time a rival rave promoter from Bozeman tear-gassed one of our parties), the things we did together were just really fun.
How did we do it? I think two things were really important, and those things stayed with me. One was learning to pivot away from drama towards action (a lesson I’ve had to relearn every two or three years, unfortunately) – we could all sit around and complain about how nothing ever happens in Missoula, or we could channel that frustration and ennui into throwing a party. The other was that you get to choose how you deal with other people. You can choose to be critical, “realistic”, cynical and whatever; or you can choose to be supportive, positive, and build connections. One of those feels a lot better.
What I’m talking about here is empathy, and empathy is something that is hugely effective for dealing with open source communities.
The first and most important tool I've leaned on really heavily is process. I'm kind of a terrible developer – I procrastinate, I overreach, I have no idea how long it takes to do things, I drop details all the time. Having a load-bearing process is essential part of me maintaining the facade of being a functional human being. My team's process is designed to make our team's workload sustainable, and it's also experimental - we tweak it all the time. The most important thing is that the process serves the team and the community, and not the other way around. We try things and ditch them if they get in our way.
Also, that process is much more useful when it's written down and people know about it. Both are important. We put a lot of work into making sure people know about our process and what we're doing. We try to make npm's release notes entertaining so we can get people's eyes on what we're doing.
If people can see what we're doing and how we go about it, they tend to be a lot more understanding about the reality that most of the time we're not going to be able to address their particular needs. We have a lot of stuff on our road map, and building software takes an amazing amount of time, especially if you're taking care of yourself to prevent getting burnt.
While we have some haters in the npm community, I think it’s better than most. For the most part, our users are incredibly positive, and even when they get mad, it’s generally because they expect more of npm than I think is is usual for open source. Even so, I worry about my team (and me) getting worn down by typical open-source negativity (not to mention harassment, which we have been very fortunate to avoid, by and large). I’m going to talk now about what we’ve done to manage this. I’ll say right up front that I feel pretty good about how it’s working out.
As an open source maintainer, I generally don’t hear from my users when things are going OK. I hear from them when they’re frustrated – maybe they’ve wasted a couple hours dealing with unclear documentation, or their builds are crashing after having run for what feels like forever, or maybe they need to use npm to do something else that they actually care about and they don’t get why it has to be so quirky. So they come in hot – the frustration is very obvious and right on the surface.
That frustration is real, and it deserves respect. However, the best way I’ve found to respect that is to not react to it, and to instead respond to the underlying problems people are having. Responding to frustration with frustration just creates a destructive feedback cycle, and if you instead respond in a way that makes it clear that they’ve been heard and you’re taking their problem seriously, things go a lot better.
Another thing experience has taught me to avoid is being sarcastic or glib with frustrated users on the internet. It feels like a way to defuse tension, but the thing about snark is that it’s distancing, and it also reads like dismissal a lot of the time, regardless of the intent. Venting is never as satisfying as it feels like it will be. One moment of snark can take days or weeks to clean up. I’ve had to do this enough times that I’ve been conditioned into being a far more even-keeled and sincere person on the internet. I’m not really sure that there’s a downside there, even though the process was kind of traumatic.
I’m not superhuman, though. More often than not, my first response to a new issue is a brief moment of intense irritation. I’m going to have to do a thing! Somebody thinks npm doesn’t work right! They – oh god, no – HAVE A GOOD IDEA. This is when it’s time for me to breathe, let go of my irritation, actually read the issue from start to finish, and maybe do a little digging to make sure that what I believe to be true about how npm works is actually true. Only then do I post a response. By the time I get to that point, more often than not I’ve come around to the poster’s point of view, and the discussion that follows is entirely productive (or at least civil). I do this so many times a day.
A thing I don’t do that often is apologize, and this is counterintuitive enough that it requires a little explanation. I believe that a sincere apology is one of the most useful social tools I have available to me, and so I try really hard to avoid reflexively apologizing when I see that other people are upset or frustrated. I save it for when I think it’s warranted, and always ask myself if I’m really sorry before I hit post, or if I’m just trying to get out of an uncomfortable interaction. Doing this is another thing that helps me avoid reacting, and overall it’s really paid off.
That said, I really don’t get why it’s so hard for people to apologize when it’s warranted. So many frustrating situations can be resolved if you just say “I’m sorry, and here’s what I’m going to do to make this better and make sure that this doesn’t happen again.” In my experience, an apology costs me very little but brings me a lot in return in the form of trust and goodwill.
This touches on something else my job has forcibly taught me: being the same person everywhere is a huge asset. Venting in backchannels, gossiping, and shit-talking, as I said before, don’t actually make me feel that much better, and when they get me in trouble, it’s both embarrassing and annoying, because it feels so much like an unforced error. Even when it doesn’t come back to haunt me, I know that I’ve been doing it, and it doesn’t make me feel good about myself. Enough so that I’ve slowly and imperfectly been training myself to stop doing it.
I don’t remember where I first learned this, but a thing about niceness is that it’s generally about fear of other people’s judgment, and kindness is about genuinely trying to help them out. My job forces me to make hard decisions on a regular basis. I haaaate closing feature requests. They represent somebody else’s time, effort, and energy. But sometimes there’s just no way that an idea is going to make sense for npm, and the best thing I can do is clearly and simply explain why while thanking the person for their time and work. The weird thing about how much I dread this is that it almost always works out positively, even when people are disappointed. When people understand that I’ve actually heard what they need and I give them a good explanation for my decision, they’re almost always nice about it.
So why did I spend all that time bumming you out about burnout before I started talking about this? Because if I have learned one thing in my open-source career, it’s that writing code is easy, and responding to the npm community’s needs authentically is really hard. A couple hours spent dealing with issues is at least as exhausting as a full day spent buried in a debugger or writing code. That social energy takes time to recharge and requires me to pull myself away from the issue tracker and go be a non-internet human for a while.
I’m extraordinarily fortunate to be part of a really supportive team. I have people around me encouraging to slow down, to let go of things that are stressing me out, to go home at the end of the day, and who have enough experience with the kinds of things I’m doing that we can commiserate. I’m convinced that doing this kind of work is much harder (or maybe even impossible) without a strong support network. Not everyone has a company behind them, but if you’re working on something popular or useful, there are probably people out there you can lean on for support. Do it. If all else fails, I’m pretty easy to find, and I want to help.
Because we are all in this together. That is the greatest blessing and curse of open source software. After 30 or so years of free and open source software, it’s hard to imagine a web or a software industry without it. And while that’s frequently stated as, “software is eating the world,” it also means we’re all dependent on each other and the work that we produce to keep moving forward, and that’s hard in its own way. It’s good to remember and honor that when we’re having a tough time, or are dealing with somebody else having a tough time.
The net effect of how I deal with npm’s community is that it feels very unlike a typical open-source project. The default OSS interaction style tends to be pretty cold. It’s easy to get away with being a jerk. Why would you subject yourself to that if you could do – anything else? I can’t live like that, which motivates me to work hard to create the kind of environment I am comfortable and happy in. As I said, this is the best job I’ve ever had, and I want to keep it for a while. Whether it’s due to the work that we’ve put into managing the community, or whether we’ve just been really fortunate in who uses our software, it is nice to work on npm. This is what I mean when I say that acting practically leads to an ethical outcome – even though the motivation for what I do is selfishness, the result benefits everyone in the community. I’m thankful to be a part of that community, and I’m thankful that you’ve given me so much of your time. Thank you.