S1 E19: Chris Slowe, Reddit

We're about a year older than Twitter and we're about a year younger than Facebook. And so there just wasn't a lot of common knowledge on how to actually build and scale things. For most 20052006 my life consisted of get up, go to work, which was my PhD work, come home at night, you just cook dinner, do a night shift on Reddit, and then lather words repeat. I think I've learned in my career that the people who, especially on the infrastructure side and the SRE side who do best are the ones who under pressure just kind of like either get better or just kind of don't panic. I'm Chris Slow. I'm the CTO and founding engineer at Reddit.

This is Code Story, a podcast bringing you interviews with tech visionaries who share in the critical moments of what it takes to change an industry and build and lead a team that has your back.

Welcome back.

I'm your host Noah Lapart and today we talk with Chris Slow about early beginnings and being the founding engineer building the world of Reddit. All this and more on Codestory. A tech and science minded individual, Chris Slo has spent nine years with Reddit. Beyond being a tech executive with the company, he is a dad and likes to work with his hands in the machine shop. When he put roots into the product.

And the company as the first employee.

He and the co founders wanted to.

Build a place to discuss interesting topics.

Fast forward many years, Reddit is now the premier place for news aggregation, content.

Rating and online discussion around what's going on? Well, let's jump right into it. Tell me how you got started building Reddit and tell me what Reddit is in your own words.

Sure. I'll start with Reddit is. So Reddit's kind of changed in what it is over time. I think the best way to describe it right now is a network of communities. It's a bunch of communities that exist in a place where users can describe and interact with their passions and interests. And I think the starting point of Reddit, going back to the early days as a product, is we wanted to build a place to share interesting and newsworthy articles and just have a place to discuss them. So I think if you want to talk about the roots of Reddit as a product, it really is kind of like an evolution on top of Slashdot or even delicious popular if you want to go pretty far back there where there's a bunch of stuff on any given day that's just really interesting and engaging and it's a format to actually discuss it. You know, another kind of like even older idea would be it's like, it's like the evolution of the forum as an art form as far as like the how did I get involved and how did I get started? So I was actually, so I was the first employee. I started there about six months in roughly. And at the time, the way I got involved is I had kind of sidelined or sideways come into the tech scene in about my fourth year in grad school, where I had a friend of mine propose to me what amounted to being a startup. This is in 2004, when startups were a bit of an anathema, given the fact that everyone was still kind of recovering from the 2000s crash. And so at the time we were trying to solve a problem we had, which was like finding documents, a couple science nerds, and long story short on that, it turned out that we ended up going and getting into the first Y Combinator batch, which is the same batch that Reddit was in. You know, Steve Huffman and Alexis Ohanian were in that batch of starting Reddit. And long story short, end of that summer, my startup had failed utterly and I had two free bedrooms in my apartment. So, you know, as good friends with Steven Alexis, they moved in. And it was about two months later that I was kind of working on Reddit as well in my spare time. So for most 2005, 2006, my life consisted of get up, go to work, which was my, you know, PhD work, come home at night, you should cook dinner, do a night shift on Reddit, and then, you know, lather, rinse, repeat. So I think I was about getting four hours of sleep that whole year, which is, you know, your, your twenties are a magical period of time where you can do that and eat garbage and not die. So I'm definitely happy that, happy that all landed at the same time.

So, so I, so I hear the process, the four hours of sleep at night that coming home, doing a night shift on Reddit. Tell me about that build process about the MVP build for, for Reddit. What'd you build it using? What you know, how did that process go and what were you thinking during it?

Oh man, this is going back to really, this is right before I started. So the first month of Reddit, Steve single handedly got together an MVP that took less than a month to build. And the original version of Reddit was actually written in Common Lisp. So Y Combinator is founded by Pell Graham, among others. And Pell Graham is a big Lisper. And so it just seemed like an obvious choice to show Paul that it was possible to build a modern web app using a technology like Linus. And so he built that and launched it. I think Reddit was actually one the first products that summer to launch, which is just incredible. The company started in June. I think it was actually live on 28 June, which actually to this day has become the official internal Reddit birthday. And that was fairly minimal. So if you think about the Reddit as a mechanic, the mechanic that's been there since the very beginning is voting. Every post and comment on Reddit has a couple of voting arrows that are, you can either upvote or downvote something and that was in there in the first version. The original version didn't have comments. In fact, the original version was the listing of links that went to other sites. So it really was initially kind of a link sharing site with a voting mechanic and a way to sort based on kind of a popularity ranking. And that was just about it. Oh, and the alien. The alien's been there since the beginning and has had definitely a major impact on our company culture and our brand. But yeah, that was about it. We didn't have comments until easily six months later. It was like kind of start of 06 where we actually went to those.

Can you tell a little bit about the story behind the alien and how like, what it means and what it represents.

So this is Alexis, you know, one of his major marks on us during the formative phases of kind of thinking about what Reddit was going to be, he was literally just doodling in a notebook and he kind of doodled the alien and he created this backstory. He's like, it's kind of adorable and it's kind of quirky. And he created this backstory of it being a. Of an alien from the future who kind of tells you the news. And you know, one of the early attempts at, before they actually picked a name of Reddit, they had tried really hard to get something along the lines of news or what's new? There was an original mock up where they had, they had created this thing called this site called Snoo S. You know, apostrophe S. N o O. It was hard to get a domain name. It was easier to get a domain name then, but it was really hard to get that one even then. And they never quite got it. And so. But the name stuck on the alien. So we've been calling him Snew ever since.

This episode is sponsored by Vanta you're a startup founder. Finding product market fit is probably your number one priority. But to land bigger customers, you also need security compliance. And obtaining your SOC2 or ISO 27001 certification can open those big doors. But they take time and energy pulling you away from building and shipping. And that's where Vanta comes in. Vanta is the all in one compliance solution, helping startups like yours get audit ready and build a strong security foundation quickly and painlessly. How, you ask. Vanta automates the manual security tasks that slow you down, helping you streamline your audit. And the platform connects you with trusted VCSOs to build your program. Auditors get you through audits quickly and a marketplace for essentials like pen testing. Join over 8,000 companies, including many Y Combinator and TechStar startups who trust Vanta. Simplify compliance and get $1,000 off advanta.comCodeStory that's v a n t a.comCodeStory.

So.

In the MVP, maybe a little bit after that, what sort of decisions, trade offs was made when it was being created as the product maybe progressed through that next sort of six months before comments came about what decisions and trade offs did you, you guys as a team have to make and you as the lead engineer have to make and how'd you cope with those?

Well, so I think, you know, during those, that period of time like one of the first decisions was, you know, which should be written in right? Because Lisp is Lisp, you know, at the time was it still is kind of a niche language. And so thinking forward to scaling up a company, scaling up a stack, I don't know if we were as deliberate at the time and project back my opinion now on this but you know, even then it was like finding people who can write in. Lisp is a pretty small set even among cs. And then part of an ecosystem of building out an app is of course the ecosystem of the, of the language you actually use. And so it was probably about six months later when we had decided that actually maybe something like Python was the right answer. This is actually, you know, this is before there was like a really big split between Ruby and Python. And in fact, you know, both of them seem like perfectly reasonable options at that point in history. And so we just kind of picked Python because it just seemed like a reasonable, simple, straightforward language and it's actually proven out to be a really powerful one. It's got a nice thing about Python is that the coding style is very well defined and it's very straightforward to look at. Code and tell it's bad the way it's formatted, which is kind of a delight when you're doing multiple people writing it. So we did a little bit of soul searching and decided late that year, one of the first things I did was help out in that rewrite from Common list to Python and at the same time start to think about the underlying architecture of how to build a site up that could actually scale. And so early on, one of the early problems was making sure that the front page could be really fast and that given the number of votes cast, we could actually not have to constantly dynamically compute that listing for every page view. And so there was a really early choice of how to do that sort that we call the hot algorithm, which has honestly been pretty much unchanged for most of our history. We've improved it, we've modified it, we've made it smarter, but the underlying mechanics of how we compute the time versus votes has been a pretty constant standard for that since then. And that was probably the first reality, drastic change. And then from that point on it was like product changes kind of stacking on. Adding comments was the first one. I think adding comments is actually kind of funny because it was the first time when we directly encountered the snark of the community, which was, I think one of the first, one of the first literal comments was something along the lines of, oh, well, I guess now it's turned into Slashdot. It was a nice while it lasted. See you guys later. Which, you know, every. Everything we do is of course the end of the site.

How did it progress after that?

Well, so from that point on we started to say one of the big things early on was honestly just scaling. You know, the thing about Reddit that we didn't really understand at the time was that it kind of had immediate product market fit. And so like, the traffic was never a problem, it just kind of grew on its own. And most of the work we had was, I think, I think in the early days we were on about a three month doubling cycle, which, you know, isn't, isn't as meteoric as some sites have been, but definitely when you're under the gun of like, yeah, you can actually see week over week a noticeable difference in traffic. You can actually see on the slope of the weekly traffic. There's a slope, you know, even normalizing for weekends was a little bit, you know, both delightful and harrowing at the same time. I think we actually, it was more the harrowing side and we spent a lot of time over the course the first four years just making sure things scaled. You know, part of that problem was that for that time there just wasn't the same kind of like common practices for how to actually build and scale a website. You know, 2005, 2006, I think we're about a year. We're about a year older than Twitter and we're about a year younger than Facebook. And so there just wasn't a lot of common knowledge on how to actually build and scale things. So we had a chance to actually kind of build it and learn it live and just discover all the silly things that we didn't know about like configuration of postgres and arcane settings or even basic settings like what they actually do. Which was exciting for sure, because usually you're discovering those things while the site's down and while your users are complaining that the site's down.

This episode is sponsored by Kinsta. Between juggling client meetings, managing your website and keeping up with everyday tasks, who has the time to stress out about website security? Well, with Kinsta the technical stuff is taken care of so you can focus on what you do best. Kinsta provides managed hosting for WordPress, offering lightning fast load times, top tier security and unmatched human only customer support. Whether you're a business owner, web developer or running a digital agency, Kinsta makes managing your website easy and efficient. Kinsta provides enterprise grade security being one of the few hosting providers for WordPress with SoC2 and other certifications guaranteeing the highest level of security for your website. Thanks to their unlimited free expert led migrations, Kinsta ensures a smooth transition for you from other hosting providers. Customers have reported 200% faster load times post migration to their platform. What I find cool about Kinsta is their fast and reliable customer service and premium features that are included at no extra cost. Ready to experience Kinsta's hosting for yourself? Get your first month free when you sign up at kinsta.com today. That's K-I-N-S-T a.com how did you go.

About building your engineering team? So you know, how did you structure the team along with the product development as you focused on scalability and adding new features? How did you build that team? And most importantly in that question, what type of people were you bringing onto this team?

So for the first six years the engineering team was never bigger than about five people. We got acquired by Khan I Nast in the end of 06 and became effectively a startup inside of a larger company, which was great from the standpoint of we had A larger company to kind of show this and learn from. But it was tough in that we never went through the initial like funding rounds. Growth, grow the company, grow the business, grow the staff. And a lot of that actually didn't come till much later. So Reddit was owned by kind of Nast until 12, at which point it spun back out as a private company and it took its series A right around that. So, you know, right now I work at a 550 person Series D startup that's been post acquired. And so if anything, a lot of the, a lot of the growth on the engineering side has happened the last. Well, it's not even a little. It's like all of the, all of the growth has happened in the last five years. During the very early days, we hired what I would say are some really brilliant generalists who were willing to take a chance and, you know, shared our level of crazy would be my best way to describe it. You know that it's reasonable to have a giant site with only five engineers running it. Right.

That makes a ton of sense.

So in those generalists, what made them so special? What were the characteristics that you looked for and you're like, that person is the winning horse.

I think this wraps up in a way with some of the mythos around the 10x engineer that has kind of pervaded the tech scene over the last decade. There's definitely a class of engineer where it's not that they're necessarily the good ones anyway. I'd say it's not necessarily smarter or better than a typical engineer. They're just willing to dive into basically any problem and try to fix it. And I think that that's the makings of a generalist. There's a certain figurelessness. You have to have to be able to take a technology stack they don't know and dive in and figure it out and then just can kind of keep repeating that when there's that kind of gun to your head of we're down, figure it out. It has a very kind of clarifying moment of like, you know, it definitely separates out people who like how you behave under pressure. I think I've learned in my career that the people who, especially on the infrastructure side and the SRE side who do best are the ones who under pressure just kind of like either get better or just kind of don't. Don't panic. Some people panic and it's just kind of their. It's kind of in your nature to panic, whereas like other people just kind of like just get Kind of calm. And I actually, I discovered early on I kind of fall into the second category of like, okay, emergency, what do we know? And just kind of like drill into it. So I think that that was something that kind of naturally comes out. The nice thing about a small team is honestly everyone has to know what they're doing or you're kind of doomed. And so everyone has to kind of like not just have a notion of what everyone else is working on, but be able to kind of fill in the gaps and identify places that things aren't working. You can't, you can't have something dropped on the floor when you have a five person team because then everything is dropped on the floor. I think it's really that, that makes it the differentiator for us in those early days and among a certain subclass of tennis engineer, to be honest.

So when you say they have to.

Know what they're doing, you're not saying they have to be, you know, super senior engineer or whatever because you're mentioning them as a generalist. But more if they have to know what they're working on, how it affects the overall team, what the other team members are working on. So they have to be. It's like an awareness factor.

Yeah. I think it's also just an acceptance of there's a set of things that are unknown and they are knowable. Right. Like this, this kind of march into the burning building, there's a problem or like, hey look, let me run in and try to try to fix it. And you know, independent of technology stack independent of opinions of like what's the right answer. You know, sometimes, sometimes the job is, yeah, there's some gnarly code base that we all built together and we're live debugging what's going wrong and not making it about, about blame or about like some sort of religious war on what technology to use. I think that's kind of a, that's, that's a valuable component I think into especially a small startup where you know, if you, if you're getting stuck up on, on kind of religious wars on technology, then it's just, it's a waste of time. Like everything you build, you're gonna rebuild in six months anyway. So you might as well pick the thing that makes the most sense right now. Try to standardize as much as possible to do duplicate effort, but really just kind of drive and build and then just accept the fact that yeah, you can burn it all down later anyway.

So you know, you're one of the founding Engineers of Reddit, you've been here since the beginning. You've been here, you know, acquisition, post acquisition. You know, you've seen it grow, you've seen it scale. You've been a part of this from the beginning. But what are you most proud of throughout the whole cycle in the technology and the product?

So I think that, honestly, the fact that there is code in production right now that has my git blame on it and has for about a decade, makes me really both happy and dreadful at the same time, because I remember that guy, he didn't necessarily know what he was doing, but the result is kind of proven out. I think the fact that, I think that what I'm actually proud of is the product itself. I mean, Reddit is. Reddit is successful. It's as much the technology as the people. And I mean that both on the team, on the side of the people who built it, and the people who make the platform, you know, Reddit is kind of nothing without the community around it. And I think the fact that we kind of like half stumbled, half discovered, half built what amounts to being this, like, lovely, vibrant, dynamic set of communities where people can kind of be them, be themselves, and be authentic and create niches to talk about things that we would have never dreamed about, you know, in the early days. I mean, it's just fantastic. Like, I can't, I can't imagine. I'm just incredibly proud of that.

Let's flip to the other side of that coin. Tell me about a mistake that you made and how did your team respond to it?

I mean, one of the mistakes is the fact that I've got code in production that's been 10 years old. Let's talk about that one. No, it's funny when I, you know, so I've had two students here. I came back in, I came back in 16. And ever since I came back, one of my recurring missives has been, any code that you find that has my blame on it, just assume it's wrong and rewrite it, please. I, actually, when I, one of the, One of the early things that happened when I, when I, when I kind of returned was, I think it was about. It was probably the same day that I got my employee account back that somebody tagged me on a pull request review. And I looked at it and it was a bunch of JavaScript code that was like kind of deep down in the guts of the stack. And my first response was, so I pinged them back. I'm like, why did you pin me on this? So at this point in my career, I had been gone for about five years, had mostly done back end work and data science, and the response I got back was just this bone chilling. Your blame is on the code. Oh, God. Okay, so new rule. Any JavaScript that Chris wrote, please rewrite. Because that was a long time ago and I don't want to, you know, be remembered for that. Yeah, in terms of like actual direct, that's kind of one class of mistakes, which is that, you know, we do have a whole bunch of stuff that needs to be cleaned up. I think, though, that the other side of that, that problem is that, you know, there's always a lot of talk about kind of like, everyone complains about tech debt, everyone complains about that this thing wasn't built right, or we chose the wrong standards. I think of that as actually a luxury to be able to complain about tech debt. And I say that because if you're complaining about tech debt, it means that you have the time to actually clean up the stuff that you're building, as opposed to just having to deal with whatever disaster is currently happening, whether it be traffic isn't there or the site is down, or any of a number of existential problems that can happen to a business. And so, you know, when you're at the point, when you're dealing with tech, that it actually means you've got certain amount of success and you can actually start dealing with it and make things better for the people down the line. It's almost like building for your children. Like, the developers that are hired a year from now should not have to deal with the foibles and mistakes of us right now. So let's try to make the system better for them. You know, the other side of that is I've come to just kind of accept that, you know, experience is really just kind of a collection of mistakes and failures. Right. So if you're going to. This is why I actually would rather try and fail than optimize towards something perfect in the first pass. Like, we really have a. We try to have a very explicit kind of MVP culture here. Not because we want to throw things against the wall and see what sticks, but because I'd rather throw it against the wall, see if it works, and then tear it down, than just kind of like try to build the perfect thing and find out that it's completely wrong. Like, we missed an entire avenue.

What is next for Reddit?

What's the future look like for the product and for the team?

For the product? I think that the core is Actually a very kind of unsexy, undrastic, like, we're going to continue to enable communities to grow and to flourish. I mean, I think the underlying. It took us a while to kind of figure out how Reddit actually works as a product. And what we've kind of discovered, especially with the last couple years, is that the things that work best on Reddit from a product standpoint are products that actually work through community. So we, as engineers and as product people, are responsible for building tools to make the community experience better and to make it richer and to basically let the creativity of the community flow in interesting ways. And so, you know, an old example of that would be one of the decisions we made early on, which ended up being a really good one, was we let communities self style with CSS directly. So giant, powerful toolkit, very obtuse to use, but you can basically do whatever you want in the way that your community lays out. And a side effect of that relatively simple yet complicated change was that we found all these avenues for expression in communities and a whole bevy of features that people built entirely with CSS and some really complicated styling, like flare and just kind of like labeling of things and just exciting ways to do voting that we're able to use that to basically foster our next round of what kind of products we build. You know, so really it's like this. It's the creating and fostering an ecosystem has been kind of the focus for us and I think will continue to be. So I think when it comes down to like, the actual, like, internals, I mean, for me there's just a straightforward, like, just continue to grow and, you know, grow the team, grow the people, grow the talent and let them be, you know, help with the creativity that's going on in the platform.

From a technical perspective, who do you look up to? Who influences the way that you think, architect, code, build, et cetera?

The easy one is probably Steve Huffman, our CEO. We've worked together for 14 years and it's really nice and comforting to have somebody that I work closely with who we've had a lot of our fights already, which is kind of good. And at the same time, you know, Steve was the first engineer on Reddit. Steve built the original stack. Steve was Lisper who kind of started the whole thing. And it's been really fun to kind of both of us have been stretching into our respective roles over the years. Like, you know, we're always working for the biggest company we've ever worked for, which is, you know, exciting and terrifying and kind of like learning what the new job is attached to. Our title for people in the industry who have been looking for to There's a guy by the name of Will Larson who has a really great book on engineering Managing Engineering Teams that's been really compelling. The idea is that when is it time to hire versus when is it time to refactor and how to avoid going into science project mode. Being an infrastructure engineer kind of by my core, I have a lot of sympathy for the problem. I would probably be lying if I didn't give a shout out to Elon Musk, if only because he makes cars that are really cool that I drive, has a space fleet and batteries attached to houses, and he has a company called the Boring Company that Makes Flamethrowers. That's pretty rad. I think any technologist you talk to who isn't a little bit like both excited and envious by the stuff that he comes up with and his companies come up with is probably lying. I remember hearing at one point that the Tony Stark character that they created for the Marvel movies was actually loosely based off of Elon. They've done some discussions with him as one of the cornerstones of that character. And kind of last but not least, one of my peers who I definitely respect greatly is there's a CDN company by the name of Fastly that does really great stuff and their CTO, Tyler McMullen has built some really cool technology recently around edge computing. It basically lets you ship anything you can write in WebAssembly into Fastly's Edge, which is like another layer of which I think is just just it's on that realm of being brilliant and bonkers and just a new way of possibly operating.

You just realized your business needed to hire someone yesterday. How can you find amazing candidates fast? Easy? Just use Indeed. Stop struggling to get your job post seen on other job sites with Indeed sponsored Jobs. Your post jumps to the top of the page for your relevant candidates so you can reach the people you want faster. According to Indeed data, Sponsored jobs posted directly on indeed have 45% more applications than non sponsored jobs. Don't wait any longer. Speed up your hiring right now with Indeed and listeners of this show will get a $75 sponsored job credit. To get your jobs more visibility at indeed.com podkatz13 just go to indeed.com podkatz13 right now and support our show by saying you heard about Indeed on this podcast. Terms and conditions apply. Hiring Indeed is all you need.

If you could go back to the beginning when you stepped in and you started taking on this animal. What would you do differently if you could go, start over?

This is a tough one because to go back to my original point about failure, I kind of feel like to some extent, like the. It's really the failures that kind of give you the experience that makes you succeed later. Or like maybe the successes are almost like the exceptions and the failures are the ones that actually you learn from to help to build up the successes. And so, you know, the hard part with counterfactuals is it's kind of hard to tell which bits are. Which bits are the ones that actually led to current state. That would have been important, actually. A simple example is I got into startups way back in 2004 because I randomly ran into a friend after a talk and we ended up hitting up getting a conversation going on some problem that turned into a startup. And if I had decided not to go to that talk or like any number of things along the way, it would have totally changed the timeline. I might be an adjunct professor somewhere as opposed to CTO at site that specializes in pictures of cats, which is a slightly different way of operating. Some advice I would give to my younger self would be a couple of things I invoke all the time. I find is there's a rule called Hamlin's Razor, which is paraphrased as assume incompetence over malice, which basically means if somebody is doing something that seems malicious, start off by assuming that they just don't know you exist and that they're actually just not paying attention and are incompetence, rather than assuming some sort of like, malicious intent. And 99% of the time you're actually right. A kind of inverse of that one is that there's a, there's a, there's a Latin phrase which I'm not going to try and say out loud, which basically don't let the bastards grind you down. So it's mock Latin that I think applies equally well to operating at Reddit as well as working at a place with 500 people. The Latin is actually illigidimi non caborundum, which I want at some point have a, a plaque on my desk. I think. You know, one of my jokes about Reddit as a place to work and a platform is that some of what Reddit exists for is it exists as a platform to criticize Reddit. You know, everything, everything we do is the worst thing we've ever done. And oh my God, why did we move that button that button was the cornerstone of the way the site operated. And, you know, you have to kind of go into it with a certain amount of like, you know, the who moved my cheese? Problem. And yet you have to go with a certain amount of humor just to be able to kind of, you know, day to day accept the fact that, yeah, you know what, people have opinions and we're gonna do things and we're gonna, we're gonna work with the community and we're gonna talk to them. And the same thing is true internally where, you know, people have disagreements and that's where kind of things like disagreeing commit come into play. I think that was less, less advice than a small rant I could give myself if I had a time machine.

Well, Chris, thank you for, for being on the Code Story podcast. Thank you for telling the creation story of Reddit.

Glad to. That was a lot of fun.

And this concludes another chapter of Codestory.

Code Story is a production of TouchTap, LLC and is hosted and produced by Noah Loubhart, co produced and edited by George Macharco. Special thanks to Deanna Chapman and Stephanie Campisi for their promotional support. Be sure to subscribe on itunes, Google Play Breaker, or the podcasting app of your choice. Make sure to check us out at Codestory Co or follow us on Facebook, Instagram, Twitter or LinkedIn.

Sam.