Process

186. 10x vs 1x Developer

December 22, 2020

What is best, a 10X developer or a 1x developer? And on what would you base the decision of hiring the one versus there other? It seems that a 10X developer is a legend. It's someone out there that has the strength of 10 men, or women. Whereas, a 1X developer is someone that is empathetic about the work that they do and they may not know everything but are willing to Google the solutions for certain things. They are often seen as the better team player, often easier to work with. We dive further into this debate during today’s episode, talking out of experience and from some research into the two types of developers. Stay tuned for all this and more on today’s episode of The Rabbit Hole.

 

Key Points From This Episode:

 

  • We define what a 10X developer is.
  • The importance of sharing knowledge and lifting up your team members — removing bottlenecks.
  • How good staffing plays a role in developing your programmers.
  • We share experiences of working with potential 10X developers.
  • How being laser-focused can increase your coding speed.
  • We discuss the Dvorak keyboard and its role in coding speed.
  • A list of characteristics a 1X developer could have — according to 10x.engineer.
  • Why an organization would want to hire a 10X engineer.
  • The benefit of the 10X developer and where does that come in and why is that reinforced.
  • And much more!

blog-cta_the-rabbit-hole

If you are a software developer or technology leader looking to stay on top of the latest news in the software development world, or just want to learn actionable tactics to improve your day-to-day job performance, this podcast is for you.

Apple Podcasts Spotify

Transcript for Episode 186. 10x vs 1x Developer

 

[INTRODUCTION]

 

[00:00:00] MN: Hey, Dave.

 

[00:00:01] DA: Hey, Mike.

 

[00:00:03] MN: How’s it going? We’re reaching the end of the year. Can you believe it?

 

[00:00:06] DA: End of the year. 2020, what a year. What did you think of it? I have a quick survey for you.

 

[00:00:12] MN: Oh, I’d be more than happy to fill out any survey that I have pertaining to 2020. This is not just about 2020, right?

 

[00:00:19] DJ: Oh, well. I happen to have a survey right here that you can fill out for 2020. And we really appreciate everyone listening to the podcast. It's really kept us going through the year, having you guys listen and comment on everything that's going on. And we want to keep talking to you. We want to hear more.

 

[00:00:43] MN: Right. I think that one of the things that we will make an extra effort for in 2021, I feel, is the customer participation. I want to be able to interact with the listeners who are listening and be available for any questions, or comments and stuff like that.

 

[00:01:02] DA: Yeah, trash talking. If you think that Ruby is fine and that I should get over Python, then you can let us know as well.

 

[00:01:10] MN: Yeah. We need to be more responsive for those hot takes too, whenever we pitch them out. Yeah, as Dave you mentioned, you have a survey for about The Rabbit Hole.

 

[00:01:22] DA: Yeah, let me get you the link. It is bit.ly/rabbitholesurveykebabcase. If you know what it means, then you should take the survey. If you don't know what it means, you should also take the survey. Kebab case means it's a dash. Rabbit-hole-survey.

 

[00:01:47] MN: There you go. Upon completing the survey, I will probably have your e-mail associated to the survey. That way, we're giving out a prize, a random selection to an individual.

 

[00:01:59] DA: A fabulous prize?

 

[00:02:00] MN: It's a fabulous prize. Yes. We are planning to give out a fabulous prize. The prize is going to be a cool gift, that's going to be a Raspberry Pie kit.

 

[00:02:10] DA: Oh, man. I am jealous. I feel I should get this on my Christmas list as well. I know you have one yourself.

 

[00:02:18] MN: Yeah. I do, but I’m definitely going to fill out the survey five times, so don't worry about it. You should fill out the survey for sure. And with your e-mail, we'll ensure that we'll contact you if you are the selected winner. We would probably need your address to send this over, note — that you may need to live in the United States for us to send it to you. That's probably some logistics that we have to deal with.

 

[00:02:41] DA: There's some legal stuff maybe. Maybe there's fine print about us not entering, but maybe I’ll fill up the survey anyway. Mike said he's going to fill it out five times, so I got to get in there too.

 

[00:02:51] MN: Hit us up on the survey. That is bit.ly/rabbit-hole-survey.

 

[00:02:58] DA: Awesome. On to the show.

 

[EPISODE]

 

[00:03:01] MN: Hello and welcome to The Rabbit Hole, the definitive developers podcast, live from the boogie down Bronx. I’m your host, Michael Nunez. Our co-host today –

 

[00:03:08] DA: Dave Anderson.

 

[00:03:09] MN: And our producer.

 

[00:03:10] WJ: William Jeffries.

 

[00:03:12] MN: Today, we got a question. Is it the 10X developer, or the 1X developer that's the best developer? Whose is it?

 

[00:03:21] DA: I don't know. I mean, I feel at best, you know — I’m a 0.5X developer, or I’m feeling like that lately.

 

[00:03:32] MN: Oh, man. No, no. Don't say that, bro. I mean, what is that seasonal something depression? That's a thing you got to –

 

[00:03:40] WJ: Seasonal affective disorder SADs.

 

[00:03:44] MN: Don’t do that.

 

[00:03:44] DA: I need a grow light or something, so I can get the UV rays.

 

[00:03:48] WJ: It’s okay, Dave. Most of our podcast listeners listen on 2X speed. You're a 1X developer.

 

[00:03:57] DA: I appreciate that math. Yeah. That works out. If I was a 10X developer, I’d be a 20X developer. Oh, my God.

 

[00:04:04] MN: Oh, my God.

 

[00:04:06] WJ: That will be terrible. You don’t want to listen to a 20X developer. They'd have to slow it down to 0.1 speed.

 

[00:04:12] MN: Oh, my gosh. Oh, man. Well, let's define, what is a 10X developer? Someone wants to shed light on what that means? I just googled it really quick. I’d be more than happy to read this definition from a dev.2 article.

 

[00:04:28] DA: Right. Yeah. I think that 10X is a legend. It's someone out there that has the strength of 10 men, or women. Maybe 10 –

 

[00:04:42] WJ: I think it's an easy misconception for non-engineers to have, because you have these experiences where you ask one developer to do a thing and it takes a week. And you ask a different developer to do the same thing and it takes an hour. And you think, “Oh, the second developer is clearly just better.” But there are so many other possible reasons why the one engineer could have been able to do it a lot faster.

 

[00:05:17] MN: Right. I mean, context. Like that person may have too much context and didn't share that information with the team — is one that comes to mind for me.

 

[00:05:26] WJ: Yeah, absolutely. You have the one knowledge silo who everybody thinks is a 10X developer, but is actually the reason why all of the other team members are so slow, because they're hoarding knowledge. It could be that the task was done a second time reusing most of the code from the task when you did it the first time. The first time, it was very difficult. The second time, it was a copy-paste job.

 

[00:05:55] DA: I remember talking to an engineer that was a colleague of mine — and they had a superpower and that superpower was estimation arbitrage. So, when the team did estimates, like point estimates on tickets, they were very good at knowing when the team had overestimated those stories and they wouldn't fight that higher estimation, but instead, they would take that story for themselves and be 10 times more productive than everyone else.

 

[00:06:26] MN: Wow.

 

[00:06:27] WJ: Yeah, that's a clever trick. I think also sometimes, if you have done one particular thing on another project, then sometimes you are the right person to pick up that story, or at least the right person to pair and share your knowledge, when you pick up that story. And people can get the impression that like, “Oh, this person is 10X better than everybody else on the team, because they just happened to have done a lot with the push notification API.” And so, they didn't have to spend any time reading the docs.

 

It's not that they're a 10X developer. It's just that they had already read the docs. If you had given them a different story with some other API that they were less familiar with, then maybe some other person on the team would have appeared to be the 10X developer.

 

[00:07:20] DA: Yeah.

 

[00:07:21] MN: But this person takes all the shine and is deemed the 10X developer.

 

[00:07:28] DA: I think over the long haul, the argument is that if you had all that knowledge to start with and that story was easier for you to do, if that software is going to be living on, then it's in the benefit of the team to incrementally increase everyone's knowledge and everyone's productivity and lift them up, so that the next time another story comes up, or if two stories comes up then you're removing bottlenecks. You don't have a dependency on that one person for their bus factor, or lotto factor, or whatever if they get hit by a bus, or win the lotto.

 

[00:08:15] WJ: I also think, you know, if you hire a junior developer to build your entire application, it's going to take that junior developer who has no help and guidance a very long time to figure out all of the things that need to be done from setting up the infrastructure, to the deploy pipeline to continuous integration if they're even bother – if they even know they need to do that. Whereas, if you were to hire somebody with 10 years of experience, obviously, it's going to be a lot faster.

 

This doesn't mean that one person is a 10X developer and the other is a 1X developer, this means that just in one scenario, you have bad staffing and you have not hired properly for this project. You need a blend of more experienced and less experienced people.

 

[00:09:03] DA: Yeah. There's a pretty great website out there. I don't remember if we've talked about this before on the podcast, but it's just called 10x.engineer. There's a vanity top-level domain.engineer. People are making good use out of that. If you go to this website, the title of the page is 404 not found and the behind the page is 404 not found, but it does say after that, 10X engineers aren't real.

 

[00:09:31] MN: Not found. Shots fired. Oh, man. I do have a question. Have anyone ever worked with anyone who you would deem a 10X engineer and what was that like?

 

[00:09:44] WJ: I mean, when I was a junior and I worked with seniors, I was like, “Wow. They are 10X better than me.”

 

[00:09:52] MN: Right. No, no. I mean, have you worked with someone with the ego of like, “Oh, I’m going to take all the hard stories and I’m going to run with it, because I’m faster than everyone.” I know, for me personally, especially when I was a junior, there were people who were far superior than me pairing with them as juniors. And I was aware of that and they were willing to help share that knowledge with me. Even though that person could be 10 times better than me, they were doing things that aren't deemed 10x engineers, if you will, where they were taking the time to teach and they were taking the time to show me the ropes as a junior engineer growing up, versus someone who runs with cowboy coats their way through the entire code base. Or what's another one I’ve seen? Oh, Bobby's merging his own pull request. That's a classic move right there, bro.

 

[00:10:51] DA: Well, that is definitely a way to get at least 2X faster, because you don't have to do any feedback review, rework or whatever. That's brilliant. I feel I’ve lost so many X's in my life due to PR feedback that I acknowledged. Yeah, I feel like I paired with one developer like that in my career, where I thought it was pretty good at that point, but then they had the split keyboard and Dvorak layout and used Emacs with all the key bindings, just coded at the speed of thought. Yeah.

 

I think there were more subtle things that made them faster, which I learned from – although I don't know Dvorak layout for the keyboard and I don't code at the speed of thought in Emacs. But like — they had these subtle tricks where it's like, okay, maintaining focus, not being distracted by the context of all the things around something. Just being laser-focused. It was like, “Okay. I don't need to understand the whole. I just need to understand enough to do the story.” Then carving off – setting that as a barrier, where it's like, “Okay. I will understand enough to get it done and not flail.”

 

[00:12:17] MN: Yeah. That person's got to go fast. They totally can with all that setup, with the Dvorak. I mean, I’ve heard that, I think, the Dvorak keys facilitates an individual to type faster than QWERTY, once you get the hang of it. I don't know how true that is, but I do know people who write in Dvorak are snappy, snappy typers and they can buzz through really, really quick, make a lot of noise with their mechanical keyboards.

 

[00:12:45] DA: Yeah. I mean, Jacob Odano everybody. What a man.

 

[00:12:50] MN: I do want to call out something the website earlier that Dave had mentioned, which is the 10x.engineer. There's another one just as similar to that one, but it's the number 1x.engineer. It actually goes through a list of what a 1X engineer does. It just seems like the 1X engineer is just empathetic about the work that the person does. They may not know everything and are willing to Google the solutions for certain things. I almost want to take a second to read through some of this list and talk about which ones are some of my favorite. I don't know if y'all want to join me on that really quick.

 

[00:13:36] DA: Yeah. I think we talked about some of them already. It is a really great list and it is collaborative. If you think there's some hidden trick that you have for being productive in a team of engineers, I think you can contribute to that as well.

 

[00:13:52] MN: Yeah, they have that. You can open the repo and send a pull request to update that list.

 

[00:13:56] DA: I feel like that would be the behavior of a 1X engineer. If they had some kind of tip that helped them be a better teammate, then they would do a pull request on the 1X engineer repo.

 

[00:14:09] MN: I’m pretty sure, there are any issues that's because they're 10X engineers.

 

[00:14:14] DA: Some of the things we already mentioned, I’ll just call them out from this list, like creating community and sharing knowledge.

 

[00:14:24] WJ: Says, I’ve never heard of that in lieu of nodding and pretending.

 

[00:14:31] DA: Writes codes that others can read. That's a dream. What a buddy. What a person to have in your life.

 

[00:14:39] MN: Sometimes takes short breaks to clear their head. Oh, man. I used to miss those coffee breaks. It's just like, you know what? I’m stepping out to the coffee shop, boys. Be right back. Oh, man. That’s going to –

 

[00:14:54] DA: Yeah. Like spending time on things outside of engineering. That's always good having a hobby. Hanging out with friends and family. I think it's especially important to be a 1X engineer — now.

 

[00:15:07] MN: Yeah. Oh, yeah. Yeah, I think it's just the concept of a 10X engineer is so ingrained into what I would think maybe – just like capitalism. You have to be the best you can, which includes staying up, working 18-hour shifts and being rude to everyone, so you can look like the best engineer in your organization. And it really goes over a lot of people's heads when it's more important to be a team player, versus the solo cowboy coder, merging your own pull request, not giving a damn, just doing what I want to do, baby. Just running with it.

 

[00:15:44] DA: Right. Having empathy for your team members and trying to give them feedback and lifting them up and seeing how they're doing as people like building the bonds with them. So you can have trust and have engaged in energetic discussions and build awesome things together.

 

[00:16:11] WJ: I think that this whole notion of 1X versus 10X engineers, it's all rooted in this notion that you can use math to calculate how many engineers you need to get a thing done in a certain amount of time, which is just not true. I mean, it gets back to the old adage, nine women can't make a baby in one month. Some things don't go faster when you throw more bodies at the problem.

 

[00:16:43] MN: Yeah, that's a good one right there. I do have a question I want throwing on his head though. Why would an organization want to hire a 10X engineer? If I’m a business person, I have this application with these sets of features and I know that Bobby is just dishing them out, getting the work done as fast as possible, wouldn't it incentivize me to encourage that behavior, so that those features do roll out? I’m curious. 10X developers exists and there's a market for that and I’m curious, the benefit of the 10X developer and where does that come in and why is that reinforced?

 

[00:17:32] WJ: I mean, I think if you are a business person, you think that 10X engineers exist and you maybe you've had good and bad hiring experiences in the past. After hiring one person who was not able to get a thing done and hiring somebody else who was able to get it done very quickly, you bought into this myth of the 10X engineer. I think you're motivated to try and find that same experience again, because one, it was just a much better experience for you to work with the engineer who was able to get the problem done and get it done relatively quickly and easily.

 

I think also, it's just your bottom line. You have a limited budget. You're trying to get as much bang for your buck as you can. If it's really true that you can get 10X more value as long as you hire the right person, then who wouldn't be looking for that holy grail?

 

[00:18:27] DA: Right. Especially if you're trying to race other people to the finish line of, I don't know, whatever you're doing. Like sending someone to the moon, or – Well actually, I don't know if I’d want a 10X engineer, sending someone to the moon. It's like, hold on to your butts. I don't know. Getting something to market, or just proving something. You have a limited runway or something. You're just racing against time and reason to get money, or what have you. Maybe there's some allure to that. Balancing that against sustainability and the sustained power of a strong team of engineers, I think. I’d take the 1X engineer any day.

 

[00:19:19] MN: Right. I think so too. I think, yeah, I would take a 1X engineer with someone who's empathetic and a team player that I can work with, regardless of the skills, or accolades that a person may have. I need to enjoy working with this person all around. It might be really difficult if I have someone who is obnoxious, or egotistical in that regard.

 

I mean, yeah. I would say, if you haven't done so yet, definitely check out the 1x.engineer. That website is pretty dope and try to implement those values, because I think they're really solid in what they bring to the table and what you can bring to the table in the workplace. Well, you have any thoughts? You're going to be good?

 

[00:20:01] WJ: Yeah, I think we're good. You're coming up on time.

 

[00:20:04] MN: Yo. Just like that boys. Follow us now on Twitter @RadioFreeRabbit, so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers just like you find their way into the Rabbit Hole. Never miss an episode. Subscribe now, however you listen to your favorite podcast.

 

On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me your host, Michael Nunez, thanks for listening to The Rabbit Hole.

 

[END]

 

 

Links and Resources:

The Rabbit Hole on Twitter

10X.Engineer Website