.png)
Jason Warner (VC at Redpoint Ventures, formerly CTO of GitHub and Head of Engineering at Heroku) on his path to computers, the trickiest technical problems, and programming as a superpower.
Developer Den is a series of interviews with notable developers in our community to learn more about their journey into engineering. We sat down with Jason Warner, the former CTO of GitHub and Head of Engineering at Heroku.
How did you get interested in computers?
My path to computers was a little bit different than most people's. I got a high school internship at IBM without having a computer in the house — they needed someone to carry printers and computers around the office to get a tax deduction. If it hadn't been for that internship, my path in life was going to be construction — most of my family was in construction at the time.
Do you remember any fun programs that you wrote at the time?
I did a lot of automation projects for people — like, to sweep sites for MP3s and download and organize them. Not that I should be admitting to these things! But at the time, everyone wanted to organize their MP3s. My first real project out of school for IBM was the 2000 Sydney Olympics website. We created the system where people could interact with athletes in the Olympic Village — that was really fun.
Did you go into graduate school?
Yes, I got a master’s degree — it seemed like the thing to do at the time. There was a lot of hoop-jumping you had to do to get jobs, particularly on the east coast. My wife was in medical school, so I had plenty of free time. I needed something to occupy myself other than just watching TV and playing video games, so I got a master's degree. I had joined a start-up that quickly went under, so after that I decided to join the biggest company I could find in Hartford, Connecticut. I joined Enron in 2000.
What was it like working for Enron?
Like many people, I wasn't sure if I was smart enough to make it in tech, and working for Enron made that feeling even worse. Everyone I knew who worked in programming had been the smartest people in high school and then the smartest people in college. And I was so late — everyone had been programming since age eight and they had had a computer coming out of the womb. I was at Enron at 22 years old, managing a team for the first time, working on the northeast corridor energy trading system. I called my mother up one day and said, "Mom, I don't know what I'm doing. I don't think I'm cut out for tech. I have no idea what I'm building, and I don't know what my company does to make money, but it's printing money. I just don't think I can cut it in this industry."
So I quit and went to SBC/SNET, who were doing DSL lines. I understood DSL lines! They're physical lines from a trunk to a house, and they send messages back and forth. I thought, "I completely understand what's happening here." After I left, the Enron thing happened.
Was it validating to know that you'd picked up that something didn't make sense about Enron?
Even in hindsight, for years I thought, "I wasn't smart enough to understand what Enron did." Seven or eight years later, my wife pointed out: my instincts were right. I was pointing at the wrong thing — I thought it was me that didn’t understand, not that Enron’s business didn’t make sense. So I realized, don't do that anymore! Do it the opposite way. Trust that there's something there and start asking questions to figure it out. Hone that instinct, instead of pointing blame at yourself.
What was the trickiest technical problem you've faced?
Working at Canonical [who develop the Ubuntu Linux distribution] was difficult because they make an operating system — there are technical problems all over the place. The hardest problem there was the "gold master" problem: as soon as you mint the disc, it's out of your control. Users have an expectation that the software will just continue to work forever. Ubuntu was supposed to be the easiest-to-use, most solid Linux distribution. But imagine someone installing Ubuntu at a telecom company and then not looking at it for 10 years! For instance, someone was running Ubuntu 8.04 in a factory system. They'd never touched it, never done a patch update, nothing. We had to start accounting for those situations and make plans for how to upgrade the distro in the field. That was a tricky problem.
Heroku was very different. The number of requests that Heroku got on an hourly basis was staggering, just mind-boggling, but the hardest problem was fraud and abuse. People would use Heroku to try to DDoS other services. For instance, during German school holidays, we saw an uptick in people provisioning free dynos to DDoS their friends' video game servers so they would have an advantage while they were playing. There was also massive crypto-mining — they got super sophisticated with how they would embed it in our systems, like running half of a process in one place and half in another. People will go out of their way to save a dollar on that sort of thing!
At GitHub, we faced the most externalities that I've seen in my career. It was attacked by state actors a couple of different times. There aren’t a lot of resources when you're attacked by a nation-state, and it’s not easy to get the help you need.
Now that you're a VC, do you think you'll keep doing anything directly with tech?
Programming should be a superpower for your career, not the specifics of your career. I've tried to challenge people to think of themselves as someone who does a job assisted by the superpower of programming, even if you're a developer. "I'm a distributed systems engineer, and Erlang is my superpower," for instance. Now that I'm a VC, my programming background is my superpower. I'm not going to push production code at a startup, but I'm always going to keep my skills up to date.
How do you think your programming experience will help you as a VC?
Most VCs, when they see a company, will immediately talk about Total Addressable Market or how big something could be. We're almost always wrong on that, these days! I think the actual interesting questions to answer for VCs are: how could this thing be big, how could this thing be successful? If you skip over understanding what it does in the first place, you're not going to be able to distinguish between things that vaguely look the same. I want to have a technical viewpoint of my own before I go and get 10 other opinions. I think I'll be much more informed at a lower level than most people in the industry.
Imagine that you're digging into all these emerging Heroku-for-data-science systems that are out there. But what is Heroku exactly? What does it mean to "be a Heroku?" They're all slightly different. If you asked me to go analyze an e-commerce startup, I'm not going to understand that side, but I will understand all the software development. I need to use that to my advantage.
What have you been reading these days?
Finance books, to come up to speed on some of the VC stuff. I've also picked back up my comic book collection from the late nineties. My son, who's 13, just got into comics. He and I have been going through all those collections together so that we can build those experiences of those comics. He's autistic, so he's got very narrow focus and interest areas. Our daughter was also just diagnosed on the spectrum, so I'm re-reading all of my social thinking and autism books too — I'm trying to refresh my memory on that.
You've used a bunch of different technical tools. Do any of them stand out as particularly excellent?
Heroku is still one of the most magical systems I've ever experienced. Had it been a different time in the world, I think even more people would appreciate it. It's also magical because they don't actually have to know all that goes on behind the scenes to think that it's amazing.
I don’t mean to sound clichéd, but the OSX and the iPhone were mind-blowing systems when they were introduced. I'd been using Linux or NEXT at the time, and OSX was entirely different — the magical touches with the rock-solid underpinnings. Then the iPhone came out!
In terms of software, my most productive era was my fully configured, homegrown Emacs set up in the 2000s. Especially the REPL — in fact, I wanted to ship a great REPL when I was at GitHub. In some ways I'm trying to recapture the magic I had in the three- or four-year period before I went to J2EE development, where I had to abandon Emacs and go to Eclipse.
What's your favorite technical toolchain?
I try to find something that's as stable as possible. For a long time, I stuck with Python, because Python was so stable. Then the Python 2-to-3 transition happened, and they had their own kind of instability and ambiguity. I reached for Ruby, because Ruby had become decently stable at that time. I'm still reaching for Ruby for the quick scripting type of tasks.
Calvin [French-Owen, of Segment.io] said, programming is like lifting weights. As a lifter yourself, what do you think about that comparison?
To be excellent — maybe world‑class — at any one thing, you do have to put in the time. That does not mean one seven-hour stretch on a Sunday. It usually means something every day, or on a regularly recurring basis. What Calvin was saying is that, when you do something often, the better you're going to be at this. You have more opportunities to be exposed to a new problem, a new idea, a new solution. In that sense, I would a hundred percent agree with Calvin.
It's not just reps, too, but also a diversity of the reps. If you do the exact same chest exercise while weightlifting, you're going to build imbalanced muscle. That's why people recommend doing incline press one day and then flat bench another day and then decline another day. You need a bunch of different ways to hit the muscle. Similarly, if you only ever did object-oriented programming, you're only ever going to appreciate fully object-oriented programming — try being a tourist in functional programming land.
What advice would you give to someone who is trying to get to where you are?
To be a VC? There are many different paths here. Mine's probably the least common one: be a company operator for 20 years, get to C level, and then jump over. Most people are going to keep doing C‑level work over and over again, because it comes with accolades and prestige.
More broadly, to get to where I am in my career: there are two things that stand out to me.
One is an ultimate curiosity: never assume anything. Go verify! Just constantly be learning, reading, exploring, trying, experimenting. Every opportunity, every interaction, every meeting is a chance to get better or to learn something.
One of my beliefs is, your reputation should last longer than your role. Your reputation is the only thing in your life that should be sacrosanct. Your actual job at any moment is to do your job while maintaining your reputation. There are many ways to be very good at your job — one of them is to burn other people out and be an asshole. But in reality, you have to play a slightly different game. No one will remember what you did in November of 2017. Understand that your reputation is going to be the thing that's going to last with you for 10 years. You've got to do that job to the highest degree of satisfaction, standards, and outcome, but you have to do it in a way that builds your reputation.
Thank you so much!
Learn more on Jason:
