Command Line Heroes - What Kind Of Coder Will You Become?

Episode Date: August 11, 2020

The 10x Coder is often positioned as a mythical developer who can always save the day. Saron and Clive investigate how much of that myth is grounded in truth.  Greg Sadetsky argues that coding is much like professional sports—some athletes are bound to be much better than those starting out. Brianna Wu and Bonnie Eisenman pick apart the myth by sharing how much they have had to clean up after supposed 10x Coders. Jonathan Solórzano-Hamilton recounts the story of "Rick," a self-proclaimed rockstar developer who assumed too much. And everyone considers the benefits of the 1x Coders—because what use is code without ideas and experiences to guide development? If you want to read up on some of our research on 10x coders, you can check out all our bonus material over at redhat.com/commandlineheroes. Follow along with the episode transcript.

Hello, welcome to Command Line Heroes, an original podcast from Red Hat. This is the final episode of our special mini-season, all about our jobs as developers, sysadmins, architects, engineers, and programmers. And in this episode, we're going to talk about the issues surrounding the question, what kind of coder will you become? I'm your host, Saran Yadbarek, and joining me is our featured guest, Clive Thompson. He's a journalist, technology writer, and author of the book, Coders. Hi, Clive. Hi, Saran. Thanks for having me back. Thanks for joining us, Clive. Last summer, Twitter was buzzing about a particular topic,

a particular type of coder. It started with a tweet from an investor, and it quickly went viral. In short, it encouraged founders to hire a rare breed of coder as soon as possible to increase their startup's chances of success. These coders have a special designation, 10X. The response to the tweet was, not great. Here's just a taste. One of my very best friends, she was texting this to me, like, can you even believe this guy right here? It just had the worst stereotypes about engineers that exist in the startup space. And the thing is, I've worked with these prima donnas.

I'm sure you've worked with these prima donnas. When someone says 10x coder, there's either one of two things going on. The first possibility is that they mean it as a euphemism for brilliant animal. And the second is that it means that they're trying to hire someone. They think they should be hiring a 10x coder,

but they don't actually know what they're looking for. So what is a 10x coder anyway? And should new coders aspire to be one? And if you are one, does that justify bad behavior? Turns out there's a whole history around this topic. So Clive, what exactly is a 10x coder? Well, as the name suggests, it's a coder who is 10 times better, more productive, more creative, however you want to measure that.

They are 10 times better than the average coder sitting alongside them, right? They're this sort of super person who can execute things faster, you know, write better code, more code, ship it more quickly, have better ideas, just like essentially, you know, a sort of super powered creature. That is a theory behind the 10x coder. So the whole idea of a 10x coder has never really made sense to me because it's such a specific number, like 10x, you are 10 times, you know, you're 10 times better than the average coder. How could you possibly measure that? How would you even know if anyone is five times, 10, 100 times better than the average coder? What does that even mean? Well, you know, it's funny that there's this number attached because it sort of cracks me up. Like every field has this idea that

there's someone who is just way better than others, right? You know, like they have that idea in music, entertainment, you know, sort of a star. They have that in every discipline. But in coding, they put a number on it, right? You know, it's just, it's data driven and they love to quantify things. But in this case, there's actually kind of a history behind that number. There's a reason why it's 10. It actually goes back to the 1960s. In the early days of coding, no one was really sure what it meant to do this for a living, and no one was really sure what productivity kind of looked like. They had some sense that some people seemed to be better at it than others, and they couldn't really figure out why. And so this one guy, Hal Sackman, decided to do a study where he was trying to answer a question. Do coders prefer to work in like an online system or an offline? And what online and

offline meant back then was offline meant kind of working, you know, where you wrote your code on punch cards and then handed it to a punch card operator and they fed it in. And then three hours later, you found out whether or not your code worked, right? Online meant you could sit in front of a screen and a keyboard and you could type and you could execute your code right away. A more modern way of coding. That's the way we code today. But online coding was really expensive because those computers were really expensive. Are people so much more productive that it's worth spending the money on these expensive online computers? So Hal Sackman said, okay, I'm going to give a bunch

of coders the same task in online versus offline, and I'm going to see how well they do. But he discovered something so remarkable to him that he sort of focused on it. The people who were doing this test, there was a subset of them that were way better than everyone else. Like the delta between the really good and the really bad is massive. Sometimes people were 20 times faster at solving a bug than other people. Sometimes they were 16 times faster at writing a piece of code. It's kind of like there's this order of magnitude difference between the really great performers

and the really bad ones. And that was the beginnings of the 10X mythology, that people who are really good at coding are rare and they are 10 times better than everyone else. From there on, the myth sort of grew until it is what we have it today. Am I comfortable announcing on air that I am part of that? You know, maybe if you grill me a little bit more,

but right now I'm feeling a tiny bit shy to say it out loud. Greg Sedetsky has been labeled a 10x coder. He founded a company called Poly9. He received one of the highest civilian awards from the U.S. Coast Guard for creating a map that helped rescue 1,700 people during Hurricane Harvey. A pro player in whatever sports is undeniably extremely much better than an average, you know, somebody who plays sports or who's just starting out. So as in other fields, it's the same in software engineering. And I definitely can vouch for the fact that they exist. If you have a startup and you know that you

need to be on the market in a month, the supply of people that can do the work in that amount of time and bring you where you want to be is smaller than the supply of people who can do the same work in three months or a year. So there's just less people who can achieve these things. So Clive, there's the pretty famous book, The Mythical Man-Month, that came out in 1975. How did the idea of the 10x coder get further entrenched with that book? in software development, whereby if a project had like, you know, 20 people working on it, and it was really late, in any other industry, like say you're building a building or digging a ditch or, you know, building a fence, the way you move faster is you hire more people so that more hands can just, you know, get that done faster. But in software, often the opposite happened.

If you had 20 people working on the project, and was late and you added 10 more people, the project slowed down. Why is that? Well, part of it is that there's a lot of get bogged down in organization. But he also reiterated this idea that there was, you know, a handful of people that were just better at this than everyone else. And so he's like, look, if you had like a huge team of 200 people, and 25 of them are doing most of the work, then just get rid of the other 175. And just have your 25 superstars, and everything's going to happen faster. You know, it's sort of so flattered, the fantasy that a lot of software developers have that they are the 10x person, right? That they are, you know, the sort of colossus who bestrides the world like a giant, you know, with all these ants scurrying between their legs. It definitely is a lesson that a lot of people quote from it. And

every time someone came along, this mythology just got more and more cemented in place. In terms of where the myth comes from, it's from people who would build tools that were wildly successful, and they would build them on their own. And then would sometimes be very aggressive and actually harass people who tried to contribute. Bonnie Eisenman is a software engineer at Twitter and author of Learning React Native. She thinks that the tech community mythologizes the 10x coder and makes excuses for them.

I think there's always going to be a place within startups for someone who can build a proof of concept really quickly, right? When you're working at a startup, the thing that you need to do is really quickly build something, get it to market, see if it works, see if it sticks, see if you can raise funding. So I think that we don't need 10Xers exactly in order to do that. We need people who are able to produce really quickly while still being decent human beings. So 10Xers are glorified by many people in the tech industry, but specifically by venture capitalists. Why is that? Well, from a venture capitalist point of view, what are they doing? They are trying to find a small new company that they think is going to produce a product that is just going to become absolutely massive.

And they also want it to move incredibly quickly. So it beats everyone else, you know, first to market dominates. So that tends to agitate towards wanting a team that is very small so that it can iterate quickly. And also a team that can sort of do everything, you know, soup to nuts, the whole stack. When I was talking to Mark Andresen, who really believes in 10X, he says it might even be a thousand X, right? He says, you know, look at these really big pioneering pieces of software that changed the arc of their entire industry. You know, Photoshop, Doom and Quake, the original video games, the original Netscape team, Microsoft Basic, right?

Very often you're talking about two to like three or four people. And he goes, that's because there's a type of magic that those highly productive people can do when everyone else just gets out of the way and they can build that crystal palace in their mind. So that's why venture capitalists really love it because there's a reality and there's also a great myth that makes for a really good story too, right? Because they have to take this dog and pony show and sell it to other investors. And it's really mythologically and narratively great to be able to say, here is the brilliant software king who

did all this. Here is Max Levchin who single-handedly coded PayPal into existence, which he really did, right? He actually created that prototype. He had spent years and years banging away on mobile software and crypto and payment software. And so he just, he just willed that into existence by himself, the first prototype. So the stories really do exist, but they're enormously marketable and mythic for a venture capitalist. Venture capitalists might love 10Xers, but it's a different story when you have to work with one. I do think that it is not necessarily the case that one is born a Rick and lives a Rick and dies a Rick. I think it is more the case that under different kinds of pressure,

people are pushed into different kinds of corners. And for some people, I think particularly people that have achieved a lot of success in the past on their own initiative and through their own work and without relying on other people, when things get really tough, you need a community to support you. Jonathan Solarsano-Hamilton is a senior site reliability engineering manager at Procore Technologies. Years ago, before he worked at Procore, he worked with a man he nicknamed Rick. Rick was a 10x coder, and he was a problem. Every week there was a new surprise reason why he hadn't achieved his deadline or hadn't met his quota or bugs closed or whatnot that he had agreed to. And it was always the result of somebody else failing to do something that they didn't even know they were expected to do. There was a very, very large portion of the code base to which Rick was

the sole contributor. So there was no code review process. It was just Rick pushing up into master, if you will, time and again, without any other eyes on that. And so the initial commitment that we made was to take two of our most senior engineers and put them side by side with him while he was doing his work, just shadow I came in and I sat down to pair with him, but he had come into work three hours early today and just did the bug fix before I even got in. And then he didn't want to go back and revisit it with me because he said it would take too long to get us up to speed. And so we started to take a little bit more of an assertive approach. What if instead we task them with being sort of the first point of contact and being the owners for different parts of the code base that he currently is the sole owner of.

And any requests for changes or bug fixes or whatnot would have to go through them first, and then they could escalate to him as needed. But that didn't succeed either. When another developer released a fix to a part of the code that had been broken and causing major problems, he went into the code base and actually reverted that fix because he was pretty angry if they had the audacity to touch a part of the code base that hadn't been officially given to

them. The real tipping point was the crushing morale problem that his presence made on the rest of the team. The more we tried to get them involved in helping him, the more belligerent and intransigent he became. And it was really a vicious cycle. The product got so delayed that the company eventually fired Rick. After that, team culture improved. The product shipped in six months, with very little of Rick's original code left in it, and it was a success. Here's Bonnie Eisenman again, software engineer at Twitter.

I've seen the sort of wreckage left behind from them. You know, I've seen teams where they think they have a 10x around their team, so literally everyone else on the team is just clammed up and frozen and feels like they can't put forth any creative output, which really sucks to observe, you know, because you have all these other people who are basically not being mentored and not being grown into better engineers. So Clive, you talk to a lot of coders for your book. What's the consensus about 10X coders? Are they a necessary evil or an unnecessary appendage from the bad old days of coding? I found that people are very divided about this question of 10x coders. There is a chunk of people who strongly believe it's true that a minority of coders are wildly more productive and creative than the others, and that everything should be done to hire them and give them as much work as

you can. And there was another cohort that thinks that is absolute nonsense and that this is just a bunch of ricks, right? You know, people who are talented, yes, but just so belligerent and terrible and full of themselves that it destroys morale for the rest of the company. It creates bad code because they're writing a ton of stuff that no one else has set eyes on. There's also the point of view, which I think is true, even for people that call themselves 10x coders, which is that they'll be like, look, I'm amazing and I generate a ton of a mess because I'm just working so fast and so intensely. Max Whitney, she's been working for 20 years and, you know, in all sorts of companies. She says they're just great at generating technical debt for everyone else to clean up, right? You know, yes, they sling a ton of code, but you're going to spend years fixing the mess. I think what I found is that people are really at a point in time when they are very divided about this myth and whether or not it's worth accommodating people who conform to that myth. So for managers who do end up hiring 10x coders, what can they do to keep them in check and get the most value out of them? If you have someone who really is genuinely talented in that,

you know, Max Levchin-like way, where they're just, you know, they're really good. They've done their 10,000 hours and more. They think deeply about the stack. There's two things you want to do. You want to keep them in check and you want to maybe also take advantage of what they're great at and make that really fantastic for the rest of the company. Some of that is, it's just good management. You know, it's not tolerating behavior in your company, setting that standard up high and making sure that it applies to everyone, even the quote unquote 10 Xers, right? And the second thing is making sure that they don't get locked in a box where they're just

producing stuff and no one else knows what's going on. So, you know, code review, you know, pair programming, you know, all that stuff. Now, the other side of the equation, which is like, okay, if you've got someone who's really productive, you know, can you maximize what's good about them? And the smartest companies, what they look for is not just someone who's 10x in their technical capability, but 10x in their social capability. Which is to say they are not just great at writing their own code, but they're great at helping everyone else write the best code too. And these are like what you could really call the real 10xers, right? The people who are masterful in writing code and thinking about the stack

and are masterful at helping junior developers develop, at unblocking other people. And very often I heard stories from companies that they had someone who was just absolutely fantastic in that way. They were great at doing the work and they were incredibly generous and amazing at working with other people. And they would say to me that like, you know, sure, I'm getting, like, you know, a thousand hours of work out of ten hours of this person's coding time. But when they talk to, like, ten other developers, you know,

I get ten thousand hours out of them because those people go back and they're unblocked and they know more. Those are the people that are the real true 10Xers that are enormously valuable and those are the ones that companies ought to be trying to find. Greg Sedetsky. I think that the most beautiful and proper definition of somebody who's truly good and an inspiration and somebody who's, you know, this leader that also is defining new things, inventing new things, creating things that were not possible before. A part of that definition needs to include that they're also human with empathy. Remember when Jonathan's team fired the 10Xer he called Rick?

Here's what happened within the company after that. Under Rick's regime, anytime somebody would speak up and say, hey, I think we could solve it this way, the feedback was biting and cruel and swift that they really shouldn't even bother speaking up at all. It took a little time for people to come out of their shells a bit and realize that it was actually safe to start talking about solving the problems collaboratively again. But the team started having big planning meetings, multiple days of just bantering and sharing ideas and putting things up on the whiteboard and taking them down.

And that willingness to be open and communicate and share one's ideas was probably the biggest factor in kind of turning it around. more healthily confronting each other with different ideas or opinions or being able to hash things out in a constructive and positive way with the understanding that respect for each other underlaid every disagreement. Clive, what's the opposite of a 10Xer? Well, the joke is it's a 1Xer, right? It's someone who works at exactly the pace of a normal developer. But I think if you wanted to be more clear, people who told me proudly that I'm not a 10 Xer, I'm a one Xer, I think their attributes are often that they're the person that is actually the sort of careful, thoughtful developer who instead of just thinking they can sort of accomplish this all

in one sudden romantic evening of bashing out a prototype, is like, no, no, I want this thing to work and to scale and to be reliable. I want my code to be readable by other people because they know that coding is a team sport. And so they are working much more patiently and carefully. They are talking all the time to everyone else on their team. So everyone knows what everyone else is doing. When they write the code, it's written for other people as well as the machine. So someone else can come in and read it later on. And, you know, they often have a really great sense of humor. They're good to work with. They're really good people. They're humble

about what they don't know and eager to learn it. I'm a zero-X coder because I'm a manager now, so I don't really get to roll up my sleeves a whole lot. But if I were to put myself in that pigeonhole, I would say that I hope I'm a 1.1-X coder and that I hope that I add 10% to everybody that I touch instead of trying to do it all myself. Brianna Wu is a software engineer and entrepreneur. She founded the game studio, Giant Space Cat.

I'm absolutely a 1X coder. You know, there are plenty of people out there when it comes to tech is not my ability to sit down and pour out perfect, great code that doesn't need, you know, someone else to look over it and make sure it's good. My skill has always been figuring out the roadblocks. I've always been that person that can step up and adapt and get things done. So Clive, can successful companies be led by 1Xers? So one guy I talked to, Dennis Crowley, he's a friend of mine, and he created back in the early aughts, Dodgeball. And he essentially created the idea of the check-in. It was a little service to let you say, hey, I'm at this bar, I'm at this restaurant. And he is, as he told me, the worst

coder he has ever met in his entire life. He could not get anything to compile, right? And he kept on trying to learn and failing and trying to learn and failing. And he was at companies and they would try and teach him and they would give up on it. So finally, he wanted to make this crazy check-in service. He had the idea in his head because he was a nightlife guy from New York. He loved going from bar to bar and he loved the idea. What if everyone could communicate where they were at? Like, wouldn't that just be fun? And so because he had that idea, he was willing to force himself to make some crappy prototype. And he did it. He basically learned how to program server stuff in ASP.

It's just a hairball of code. Like he's shown it to people and they just laughed at him, but he got it working and it turned into not just a company, it turned into an entirely new activity. That's something we all do all the time now. He created that idea. He's a terrible coder, like by his own admission. But if you have a really great idea and you're a proud one Xer, you can tilt the axi of the universe just as much and maybe even more than the quote-unquote 10Xers. But is that an anomaly or is that a common thing that can happen? I have very frequently run into founders and I said, so tell me your story. They're like, well, I'm not a great programmer, but I had this idea. So I just kind of made this, you know, crude prototype and it worked well enough that, you know, then we got some real developers on and now the whole thing scales and it works. So I think if you, if you scratch the

surface of a surprising number of successful startups, you'll find people who by no means would call themselves 10X coders. It would actually call themselves 1x or less, but they got things moving. As an industry, are we moving away from glorifying 10x coders and supporting these 1xers? I would say I am hesitantly optimistic that yes, we are. And I think it's for a couple reasons. One is that there's been enough attention paid to the toxic side products of tolerating abusive creative assholes. In one respects, one of the greatest things that Susan Fowler, who was a fantastic microservices engineer, hired at Uber, and she was hired and she discovered that it was just a

complete nightmare of an environment where all these abusive guys up top were tolerated while they engaged in terrible behavior, including flat out sexual harassment. And she wrote a big blog post about it. And it single-handedly created the shockwave throughout the tech industry saying, wow, this stuff is happening and it's unignorable and it's driving talent out of companies. Now, did that change the behavior of these companies towards tolerating, quote unquote, you know, 10Xers who are terrible? Certainly not always, but it did wedge that door open in a really interesting way. And you've also found, I think, an awful lot of companies I know where people have peeled off from a large organization where there was a lot of abusive 10Xers around and tolerated. And they said, screw that.

I'm going to start my own company. Yeah, I think the needle is moving. I also think that the Me Too movement is finally having a really strong impact on what people perceive as acceptable in technology. And now people are willing to say, even if you've contributed good work, we don't think that's worth the opportunity cost of you creating a toxic environment and therefore making it impossible for other people to also contribute good work. So I get the sense that something is actually changing. I really hope it does. The story of 1x coders is really the story of most of us out there. It's about how collaboration and contributing can achieve great things on the command line, not about hoarding the command line. Here's Brianna

Wu with some final thoughts. There was a line in a James S. A. Corey novel that came out last year, and I heard this and I loved it. It said, as you get older, you have to choose between being who you want to be and who you are. And that's a choice that you have to make. And I think for a lot of engineers, if you're kind of low on the self-introspection scale, it's easiest to say, I'm going to just be who I am. Gruff, antisocial, telling myself I'm really great at this. And, you know, there are tons of fantastic people in our field that stay there.

I think the true standout stars are the ones that really look deep within themselves and go, okay, I can understand the coding part of this. What do I need to then go understand about human nature? What do I need to understand about how to motivate a team? What do I need to understand about how to not let the worst parts of myself affect the projects that I'm working on? And I believe that's the bravest choice that you can have in software development. Those are the people that I want to work for. Command Line Heroes is an original podcast from Red Hat. Thank you, thank you, thank you to Clive Thompson, my featured guest throughout our special series

on the career of a coder. You are the best, Clive. Tell us how we can get your book. Oh, that's a great question. Right now, given that we have an epidemic going and people are doing social distancing, you are probably ordering the book online. You can also find a lot of links at my website, clivethompson.net. But however you get it, I appreciate it. And do let me know, anyone out there, after you've read it, what you think. I am easy to find online. For more research and information about this season, go to redhat.com slash command line heroes and stay tuned for season six. We'll be telling you the stories of eight inventors

who created technology that is now standard in our daily lives. You won't want to miss it. Keep on coding. Hi, I'm Mike Ferris, Chief Strategy Officer at Red Hat. And as you might expect in my role, I get a lot of questions about AI, particularly about foundation models. Now, don't get me wrong,

those are important, but they're not the whole story. Whether you're using a commercial model or an open source one, you're going to need to fine tune or augment models with your data for your use case. And you need a common platform for that where data scientists, app developers, and ops teams can all collaborate,

especially as you start to scale. And then this is iterative. It's rinse and repeat. So really, it's about making that fast path from idea to model to production and back again. And that's what Red Hat OpenShift AI does. Head to redhat.com to learn more.