If you’re committed to a lifetime of coding, how do you make the most of it?
Your training, experience, and passion are all in computer programming, but after a few years it can start to feel like you’re being railroaded into management, or out of the industry. Full-time programmers in their 40s or older are few, and the industry doesn’t reward long experience like it should. We can change this. We can find more creative ways to deepen our skills, get promoted, and expand our influence as coders for our entire careers.
[ sound of an old-school dial-up modem ]
My favorite part is coming up. Wait for it.
[ modem buzzing reaches a fever pitch then stops ]
So that was a 56K modem. That was the state of the art in 1997. Show of hands, who here used to get online with a 56K modem?
[ many hands go up ]
Ooh. Really? Nice. By 1997, I was in college so mostly I got online by going to the college computer science lab. It was this long narrow room lined on two sides with Linux work stations and they were always turned on and they were always connected to the internet, which was completely mind-blowing to me. But when I came home for vacation, this was how I’d get online, with a 56K modem. Let me see if you recognize this sound, though.
[ lower-pitched, more staticky modem sound ]
So it’s a 14.4K modem. Previous generation. A little more primitive. This is the main modem that I used throughout my high school. In later years when I was in high school I would use a 14K modem to connect to the internet, but early on I would use it to connect to America Online. Who here connected to America Online dial-up?
[ a few hands go up.]
Alright, we’re starting to fade out a little bit. America Online was underrated, I think. It was not the internet, it was a proprietary network, but it was a social network. It had online chat and forums and this massively multiplayer online role-playing game, a sort of Dungeons & Dragons themed thing called Neverwinter Nights.
But the sound that really has been laid deep in my brain, an ancient neuron, is this one.
[ whistling, staticky modem sound ]
The 2400 baud modem. Who here ever used—
[ hands go up, even a smattering of applause, then laughter ]
Okay. Maybe half, a third of the room. That’s the modem that I used to get online first, in middle school. There was no network to speak of. I connected my mom’s Tandy 2000 desktop computer to bulletin board systems in my local area code where I could download shareware, or I connected directly to a mail server where I could pick up my one message per week.
Which was personal, you know? It was a good time for email. So that was like my first distributed system. And that was the first way that I got online. So don’t call me a Gen X-er, call me a 2400 Baud Kid.
[ laughter ]
How Do You Want Your Role to Change?
I turned 40 in October, and around the same time I marked my seventh anniversary working the same job at the same company, MongoDB in New York City.
I didn’t really expect turning 40 to provoke a lot of soul searching, but it did. I started to think: How am I so different now, as a programmer, compared to who I was when I was 30? And what does that mean for what I’m going to be when I’m 50? Am I really transforming from decade to decade? I sort of felt like I was stuck at the same level of the dungeon in some role-playing game. Like I’d completed all the quests, I’d got all the magic items. I was just wandering from room to room, slaying a monster and then another monster and then another one, collecting treasure when I already had more than I could carry. I was looking for the trapdoor down to the next level and I just could not find it.
Around this time I had my regular one-on-one with my boss. My boss is in Palo Alto and I’m in New York, so we video chat. He was on his laptop and I was on mine. And we were just having our regular meeting and I’m supposed to come up with an agenda, so I decided to ask my boss, “What do I need to do to get a promotion?”
I asked that for lack of a better goal. I was sitting in a bright little room in our Manhattan headquarters and on the wall behind me there’s this Star Trek-style decal. It looks like a view screen on the ’60s-era Enterprise, so it’s got a futuristic border, and a star field and maybe there’s Klingon Bird of Prey. This is the background behind me.
[ some chuckles ]
And I’m asking my boss: What do I need to do to get promoted? I’ve been a staff engineer for a couple years. What do I need to do to be a senior staff engineer?
And he said, “Okay. How do you want your role to change?”
I sat there for a couple of breaths. I said, “I have no idea.” And he didn’t really have an answer either.
If you’re one of these modem kids like me, have you reached this point yourself? You’re learning one skill and then the next, and then the next framework and then the next programming language, but it’s not transformative. It doesn’t feel little you’re able to descend down through a trap door into a whole new realm that makes you into a different kind of programmer from who you were a few years before.
And maybe if you’re not a modem kid, maybe if you’re in your first decade or two as a programmer, things are good. Your first job was interesting. You’re still learning a lot. You feel like you’re advancing. That’s great. [ grizzled voice] But lemme tell ya, kid. The years really do fly by. And if you want to make anything really new, or if you want to completely understand something in one lifetime, you have to be strategic. Do you know what you should be learning and doing right now to have the deepest possible adventure over the course of one lifetime coding?
The Industry Is Young
Part of the problem of figuring out who I want to be when I grow up is there are so few coders older than me who had the kind of transformative career that I’m looking to have. I’m not saying there’s nobody, I’m just saying that the industry is really young.
Let me read you a few stats. The average American worker is 42. But the average worker at Google and Amazon is 30. This year there was a the Stack Overflow worldwide developer survey; they found that three quarters of developers are under 35 years old. And the Python developer survey that just came out, they found that half of Python programmers are under 30 and 80 percent of Python developers are under 40.
Every week there’s a discussion started on Hacker News or on Quora, somebody asks, “Where do old coders go?” [ laughter ] And people always come into the comments and they say, “Old coders don’t go anywhere. I’m still going strong and I’m 37 years old!” [ lots of laughter ]
Part the reason why the age distribution is so skewed is that new coders are entering the industry all the time. The number of computer science majors tripled over the last 10 years. But another thing that is happening is that old coders are quitting—becoming managers, leaving for other professions entirely. It’s weirdly under-studied. I couldn’t find good numbers about the rate of the exodus.
I talked to an economist who studies STEM overall, so that’s Science, Technology, Engineering and Mathematics. Kadeem Noray found that among those who do major in STEM, at the age of 24, 90 percent of them are working in STEM. And at the age of 35, only 70 percent are still working in STEM. So that is a pretty precipitous decline, and it continues throughout our careers. I think that in computer science specifically, it’s at least that bad.
So, I would love for more research to be done. I would love to know the actual numbers for computer science specifically. I desperately want to know the answer to “Where do old coders go? And why do we quit?” But in the absence of rigorous research, I will speculate.
[ laughter ]
I’ve got a theory that there are three factors that cause us to quit: We are driven out by age discrimination. We are tired out by a skills treadmill. And we’re lured out by a longing for adventure that’s not fulfilled.
We’ll start with age discrimination. There’s a great story about Mark Zuckerberg. When Zuck was 22 years old, he went to a conference that was hosted by Stanford University and Y Combinator, so this is like ground zero for Silicon Valley. And Zuck told the conference:
I want to stress the importance of being young and technical. Young people are just smarter. Why are most chess masters under 30? I don’t know. Young people just have simpler lives. We may not own a car. We may not have a family. I only own a mattress. Simplicity in life allows you to focus on what’s important.
How noble, right?
[ crowd laughs ]
So this is age bigotry spoken out loud, but we know that it is silent and pervasive in the industry. There was a study by an HR firm called Visier last year that found that programmers under 33 years old were more likely to get jobs they applied for than those over 33—even though those who are over 33 are more likely to be rated as top performers on their job. Age discrimination strikes hardest when we’re on the job market, rather than when we’re on the job.
I interviewed about half a dozen programmers older than me when I was preparing for this talk. And what they told me confirmed this image.
A programmer named Kevin Stevens when he was 49 years old, he interviewed for a job at Stack Exchange. He was interviewed by a younger engineer there who told him:
I’m always surprised when older programmers keep up on technology.
Kevin did not get that job, but he wants me to assure you that he has a nice software engineering job at a hospitality firm where he is respected.
I talked to a woman named Ari Blenkhorn who is this incredibly qualified and experienced woman. She worked for Industrial Light and Magic doing the Cloth simulation [software] that we see in Harry Potter’s Quidditch cloak or Yoda’s robe in Star Wars. Ari left her job when she was 43 years old because she wasn’t getting the kind of respect that she had earned with this experience. But when she got other jobs she just struck out. She says:
Nobody wants to pay for 20 years of experience when they could get two for the price of one by hiring fresh college graduates. Companies don’t know what they’re giving up.
Ageism, it strikes hardest when we’re on the job market, but just being on the job and having decades of tenure, it doesn’t necessarily mean that we’re safe. In the last couple of years at IBM, there was a ProPublica investigation that showed that they had been laying off their older workers by the thousands. Intel is currently under EEOC [Equal Employment Opportunity Commission] investigation for doing the same kind of thing. By the way, I’m going to share, at the end of this, links to all the articles and papers that I’m talking about.
So I want to be clear that I personally am privileged and fortunate. I have not experienced age discrimination yet. But I worry about what’s going to happen the next time I’m on the job market. And I particularly worry about women and people of color in the industry as they age as well. They’ll be subject to intersected biases and it could be career-ending.
The Skills Treadmill
We are driven out by ageism and we’re tired out by the skills treadmill. As soon as we start working in this industry, we’re in a race to stay relevant.
This economist I talked about, Kadeem Noray, he wrote a paper called “STEM Careers and Technological Change,” with the co-author David Deming. They’ve got a nice mathematical model for how skills and salary work in STEM. So we start off, we’ve got certain skills, maybe we got a college degree, and the more skills we have that are relevant, the higher our salary. Over time we can learn on the job, we get more skills and we get paid more. But also, we’re losing skills all the time to obsolescence. Things we knew that had been useful become useless.
I think of this as one of those marquee signs that’s full of light bulbs, and the more light bulbs it has, the brighter it shines. So you could add light bulbs to your sign and it would shine brighter but you’re also in a race because the bulbs are burning out all the time and it’s a race just to replace them as they go dark.
As we earn skills and lose skills over time, our salaries top out. The salary advantage we had for going into STEM, half of that advantage is cut in the first 10 years. And over time, in our 30s and 40s, we switch to other careers that have a slower rate of technological change. People become managers, people go to other professions entirely, and the reason is that they’re seeking sustained salary growth.
I personally am not that worried about salary per se. I think that salary is a proxy for value. And what I’m seeing is that our ability to increase in value over time also tops out. Because we’re being judged and employed for this marquee sign full of short-lived incandescent light bulbs rather than for the kind of wisdom that we earn over time. I’m looking for a different kind knowledge that will last. I’m looking for a way to be ever more valuable as I advance.
A Taste for Adventure
So we’re driven out by ageism. We are tired out by the skills treadmill. And finally we’re lured out by a taste for adventure. I don’t want to just learn new skills to replace old skills while staying at the same level of the dungeon all the time. I want to go deeper and deeper every year, learning new things and becoming a new kind of coder. I want to be transformed by my job.
A lot of people respond to this longing for adventure by becoming managers, and that’s always an option. It’s not an option for me personally, if I became a manager and I had to sit in all of those meetings, I would go nuts and light my beard on fire and run out the room screaming.
If you have the ability and patience to be a manager, please do, because the software industry has more managers per capita than most other professions. We need great managers. But if I became a manager, I would be one of those managers—you probably know the type—who would really rather be a coder. Who hates it and is bad at it.
There’s got to be some other option. There’s got to be some way for us to just go deeper and deeper and be more and more transformed over time so that our whole lives as coders is an adventure. That would be the kind of job that I would stay for.
So, I’ve got some solutions to propose. Everything comes in threes. My solutions start with the letters L, M and L. I want us to Learn, Mentor and Lead. I’ll start by talking about learning.
The kind of learning that I’m talking about here, it’s not adding skills to replace the old ones. It’s not just popping out a short-lived incandescent and replacing it with another short-lived incandescent. I want us to start installing LEDs that will last for decades.
When I talked to my manager and I said, “What do I need to do to get promoted?” we both basically said [confused dog noise]. I started to think about what the new grads that we hire at MongoDB, what their initial year is like at our company. When we hire a fresh college graduate, they get this incredible honeymoon, where they get to rotate among three teams for a few weeks each and then decide where they want to settle down, what they want to be when they grow up. I realized that I’ve always been jealous of that and I wanted that for myself. I wanted that opportunity to learn and try out new things, and decide where I really want to concentrate. I asked my boss: “Treat me like a new grad. Let me do rotations.” My boss was incredibly generous. He said okay. My company as well was super generous and allowed me to embark on this adventure.
In December, I left the team that I’ve been working on for seven years. I put my keyboard and my screen on my office chair and I wheeled it around the corner and now I’m sitting with a different team, the distributed systems team at MongoDB. I’m learning so deeply and so fast, I can’t ever remember a time like this before. I want to make kind of a fine distinction here, that what I was looking for—it wasn’t just learning new skills. I can switch programming languages or whatever. That’s not what I’m looking for now. I wanted to move around in search of that trapdoor that was going to lead me to a new realm, that was going to transform my job and transform me.
And I think I found it. Or I found one of the trapdoors. I think perhaps there are unlimited trapdoors, but I found one. And all of these distributed systems, theories and papers that I’d just sort of been hearing about before—like Paxos and Lamport clocks and the Raft Protocol—I’d heard about all these things, but I’d never thought, “I should read those papers. I should learn those things.” So now I am. And it’s amazing.
If this is what you’re searching for as well, maybe you should try this, too. Try a different team, or try a different job at a whole new company. Maybe you’ll find that trapdoor that you’re looking for. Or maybe the trapdoor is actually right under your feet. Maybe it’s in the job that you’re on right now, you just haven’t seen it yet. Look for it. Try to go deeper. Maybe read the first academic paper that founded the specialty that you’re working in. Or read the newest academic paper; maybe there are some new ideas coming out of the research world that will transform the way you do your job.
Or maybe whatever layer you’ve been working on in your system, it’s time to understand how that layer actually works. So if you know Python: learn C, read the interpreter. If you know C: Learn Assembler, read the compiler. If you know Requests: learn sockets. If you know sockets: Learn TCP. It’s not a hobby or curiosity, going deeper in this way will turn you into a new kind of coder, at least that’s been my experience. That’s the kind of learning I’m talking about.
The next in the set of three is mentoring. In every culture, people who are very experienced gradually move away from being implementers full time, and we spend more of our time mentoring the next generation. There are things that we know how to do from our years of experience. We’ve got an intuition for the right place to look to diagnose a bug. Or how to design a simple solution to a complicated problem. We know these things but we can’t explain them. And yet we can teach them. It’s sort of mystical, but it’s actually possible to transmit this knowledge, and that’s what mentoring is for. An intense one-on-one relationship with a colleague, working with them side-by-side, solving problems together. That’s how you can actually transmit this knowledge.
If you have years of experience, I propose that you allow yourself to shift your time away from implementing and toward mentoring. And I also propose that you particularly prioritize mentoring women and people of color and other members of underrepresented groups in tech. There’s a report from the National Center for Women & Information Technology that shows that the main reason why women tend to quit the tech industry mid-career is a lack of senior mentors. And most senior engineers are men, so we’ve got to step forward and do this.
There’s been some really upsetting backsliding in the last year in the software industry. The Atlassian State of Diversity Report found that from 2017 to 2018, individual efforts toward diversity and inclusion fell by 50 percent. It’s as if we had realized there was a problem, we spent a year or two working on it, we didn’t get very far and we gave up. We had no patience for the long haul.
Plus, articles in the New York Times and a LeanIn.org survey showed that senior men in every industry are withdrawing from mentoring junior women. We’re afraid of the Me Too movement, and we think that if we reach out to junior women in our fields it will be misinterpreted, and we’ll be accused of doing something wrong. This is very frustrating. You and I know that if we treat women as professional colleagues, we’ll be fine. So we need to step up and do this.
Besides learning deeply, and mentoring, the final thing that we can do as individuals is to lead. I know I’m pitching this as a talk about the career path for non-managers, but senior engineers do need to be technical leaders. The main way that we can be leaders is by identifying best practices. Best practices is corporate speak for something very basic: It’s craft. We have learned how to do our craft through years of experience. We know what works.
The main accomplishment that I’m proud of from the seven years that I spent on my team at MongoDB is that I developed a culture of specifying software in great detail and then getting everybody to follow the spec.
When I joined MongoDB we had a dozen different drivers, they all connect to the database server and they’re all implemented in different programming languages. There’s a particular kind of problem that they need to solve when the main MongoDB database server goes down. Some secondary takes over and becomes the primary. Every driver needs to implement the protocol for discovering that a failover has occurred and finding the new primary server, but, depending on the details, every driver had different scenarios in which it would succeed or fail at this task. So I got my team together. We designed a very detailed specification for how to do this task. Then we wrote tests that proved that everybody did it the same, and then everybody implemented it. Once that work was done, this whole class of bugs that had been frustrating us and costing our customers time and money, it just went away.
So I want us all to look for opportunities to do this kind of work, this kind of technical leadership as senior engineers. Identify practices that, if our team implemented them, would lead to better outcomes. Then persuade our colleagues to follow them, and teach our colleagues how to follow them.
Distinct Roles for Individual Contributors
As individuals, we can learn, we can mentor, we can lead. But there’s something that we need from our companies. We need them to define the individual contributor track for us much more distinctly. You know, when I was talking to my boss and I said, “What do I need to do to be promoted?” And he said, “How do you want your role to change?” There should have been an answer for that, right?
I think I sort of know, on the management track, what the difference between a director and a vice president is. Can anybody tell me what the difference between a staff engineer and a senior staff engineer really is, just by looking at what they do?
It should be possible. I don’t know the answer. But there should be an answer. Maybe it’s: At one level you implement, and then you mentor, and then you train the mentors. Or you start off implementing designs, and then you write designs, and then you train people to write designs. Whatever these stages are, they need to be much, much more sharply drawn.
If that happens, it will have a number of benefits. For one thing: We’ll be promoted faster. When companies need a manager to be a vice president, they hire or promote somebody to fill that role. But they don’t have a similar motivation to create a staff engineer, because it’s not a role that has very specific responsibilities. There’s no particular need for any of us here to fulfill a particular title on the individual contributor track.
Besides being promoted faster, it would also create this adventure that we’re longing for. Our jobs would change over time in distinct ways. The job would transform and we would be transformed, and that would create the sort of lifelong adventure as a programmer that I really want for myself. And that’s what would keep me in the industry through my 50s, my 60s, my 70s, as long as I could sit at the keyboard. It would be an intellectual challenge and it would allow me to keep doing what I love.
The Industry Needs Wisdom
So that’s good for me. If you’re committed to a lifetime as a programmer, it’s good for you too. It would also be good for our society as a whole.
The software industry is becoming so powerful, but think about some of the mistakes that we’ve been making recently. At Equifax, they knew that their software was insecure, they didn’t upgrade it, and I think it’s 148 million Americans whose data was stolen. At the Democratic campaign headquarters, an FBI agent actually called them and said, “Your email system appears to be compromised.” And yet they did nothing for weeks and it affected the course of the election. At Facebook, they’re still not taking seriously the way that Facebook is used to incite violence and hatred, the way it’s involved in the genocide in Myanmar. We’re still hearing about algorithms used to evaluate people for loans or for parole that discriminate based on people’s race, or where they grew up.
It seems to me that the software industry, it’s kind of like a teenager right now. It’s got a big, strong body but it’s got no wisdom.
So, we need to learn some wisdom fast. But that alone is not going to be enough. Because if we learn the lessons of this year and then we quit before we have a chance to pass that on to the next generation, they’ll just repeat the same mistakes. So we need to stay. We need to transmit whatever wisdom that we’ve learned out of the mistakes of this generation so that software and society have a better future. In order to do that, we need jobs that challenge us, that provide us an ever-deepening adventure from one decade to the next to the next for as long as we’re able to do them. That’s a really inspiring thought for me, and I hope it’s an inspiring thought for you, too.