You've probably seen this stereotype before, maybe in a movie or a TV show. The stereotypical hacker type. The person who stays up late drinking an inordinate amount of caffeine and has seven screens in their home computer. Their office, their room, wherever they are is always messy. But they are regarded as some kind of genius. They seem to be able to do in a few minutes what would take other people a week to do. And the number of systems that they are familiar with seems to be endless. And it's easy for us as developers to dismiss this stereotype. But unfortunately, there is a similar stereotype that prevails in our industry of the 10x engineer. In today's episode, we're going to talk about some of the core features of this stereotype. And more importantly, we're going to talk about why you don't want anything to do with this kind of label. My name is Jonathan Cottrell, and you're listening to Developer Tea. And my goal on this show is to help driven developers like you find clarity, perspective, and purpose in your careers. And before we go any further on this subject, it's important to note that there are differences in productivity amongst a given set of developers. In fact, it is totally conceivable that a developer who is relatively experienced might be able to produce code 10 times faster than a beginner, for example. And this is true in almost any profession, that the speed at which you produce something or complete some task may increase as you gain experience. This shouldn't be a surprise to us. But there's a few myths that go along with this 10x engineer, title, this label, that can be harmful. And the first myth is that speed of production is the ultimate value delivery mechanism for a given developer. In other words, how fast you code is the most important factor for your value as a software engineer. Now, the argument that your speed is not important at all is probably not true either. Somewhere in the middle, there is a sufficient production speed. And that's why I'm going to talk about how to build a speed of production speed for you as a developer. But if you only prioritize speed of delivery, then there's a whole host of other effects and other values that you skip out on. So we're going to dive into some of these characteristics, the characteristics of this of this stereotype, some of the most common perceptions of what it means to be a so-called 10x engineer and why those things are actually probably harmful. The first characteristic is that 10x engineers relentlessly avoid doing anything that doesn't produce code. 10x engineers don't go to meetings unless they're forced to go. They don't spend time writing documentation. They don't spend time explaining their code or maybe even reviewing other people's code. They'll go into their cave and produce multiple features entirely on their own and ship them to production, sometimes breaking the rules and not having their code reviewed by others. Sometimes the 10x engineer is even reticent to write tests because they know how their code works. And so there's no need for tests because tests don't necessarily produce any value to the product. They don't produce any real working code. So why waste your time on that? The 10x engineer has very little patience for politics, and they are generally not the kind of person that you want to ask many questions. For example, if you're a beginner, you're probably not going to go to this person to learn about what's going on in the code base. Now maybe you hear this and you identify with some of the concerns that these 10x engineers have, like for example, wasting time in non-productive meetings or spending an inordinate amount of time writing documentation rather than focusing on self-documenting code. And so it's not a good thing. It's not unreasonable to have some of the same kind of shared concerns. But here's the problem. When you create a position or you create a culture around this kind of behavior, and when an engineer is allowed to hold a bunch of knowledge to themselves without taking time to share that knowledge with other people or review other people's code, you end up creating, at the very least, a bottleneck. And that's holding the company that they work for hostage. Because if they were to suddenly disappear, then all of that knowledge that they didn't get out of their heads and into some kind of documentation or into another person, all that knowledge goes with them. And so what often ends up happening is the 10x engineer comes in and does a lot of work. They produce a lot of code, maybe even a lot of good code. And then the rest of the engineers, have to go and learn what that code does. They have to spend time documenting what the 10x engineer refused to document. Those other engineers have to spend time in those meetings collaborating and working through the politics of developing a product. Ultimately, those 10x engineers are insulated by the other engineers, the ones who are willing to take the time to document and share knowledge with each other. Another characteristic of the 10x engineer label is someone who is willing to work basically all the time. Their hours are much later than the average person, and they essentially don't pick up any external hobbies. All of their appreciation in life is driven towards engineering. Now again, many of us as developers, we identify with this. We love writing code. We love building things. We love building things. We love building things. We love building things. We love building things. We love We love building things. We love building things. We love building things. We love building things. We love the process of engineering so much that even when we aren't working, when we aren't doing this for our job, we might be doing it outside of our job. But this is where it becomes problematic for the other engineers on the team. In order to produce at the same kind of volume as the so-called 10x engineer, they have to sacrifice the things that they otherwise would be participating in. Another important characteristic of the label 10x engineer is that these engineers are typically working in the earliest phases of a given product. In other words, they're building kind of greenfield, and they know all of the pieces of the puzzle. They were there since the very beginning, and so they have more context for the different moving parts and pieces. This has two major effects on the team. The first effect is that anyone who comes in after the first step of the project is a 10x engineer. They're not going to be able to do the same thing after this initial kind of big sprint from a 10x engineer. They're going to be subject to all of the opinions and all of the kind of design considerations of that person. The next thing to note is that all of that context makes a huge difference on your ability to move quickly in a system. If you have all of the context and everything is built the way that you kind of naturally think to build things, then of course you're going to be able to do a lot of the work that you're doing. So if you have all of the context and everything is built the way that you kind of naturally think to build things, then of course you're going to have comparatively more productivity than the next person. There's plenty of other characteristics of the 10x engineer stereotype, but instead of continuing to talk about this bad stereotype that causes all kinds of problems on teams, I'd like to talk about what it means to be a force multiplier engineer. We're going to do that right after we talk about today's sponsor, Linode. Whether your project needs simple web hosting or maybe you have CPU intensive needs like video encoding or machine learning, Linode offers a balance of power and price for every customer. With Linode, you can deploy a server in the Linode cloud in just a few minutes, and you're going to get $20 worth of credit if you're a new customer. You can build pretty much anything with Linode. Soon, Linode is going to support object storage, Linode Kubernetes engine, and GPU processors for those of you who are getting into that machine. If you're a new customer, you're going to get $20 worth of credit if you're a new customer. You're going to get $20 worth of credit if you're a new customer. You're going to get $20 worth of credit if you're a new customer. You're going to get $20 worth of credit if you're a new customer. They have a new cloud manager that features an improved user interface. By the way, that manager is actually open source. You can find it on Linode's GitHub, github.com slash Linode slash manager. Go and check it out. They also have a restful API. If you want to build your own deployment structures, anything that you want to hook into, you can use their Python CLI to automate tasks that are, for example, specific to your business. Go and check it out. head over to linode.com slash developer T. That's linode.com slash developer T, all one word. Use the code developer T2019, that's the numbers, 2019, when you check out linode.com slash developer T. Thanks again to Linode for sponsoring today's episode. We've been talking about the label of 10x engineer, and if you've ever felt inferior because you don't think that you are one of these, you're not alone. Again, most engineers don't produce code like this 10x engineer kind of person would, and most don't want to. Engineers who isolate themselves and refuse to work well with others, this is a difficult person to get along with. Regardless of what they are delivering in their code, they're difficult to get along with, but they also cause business problems when it comes to the product itself. And so what I would prefer for myself and for the people who listen to this show is to think about yourself as a force multiplier. Rather than being 10x more productive than your peers, consider ways that you can deliver value to those same peers and help them be more productive. As a force multiplier, you recognize a few things. Number one, you're not there to hold your company hostage with your own abilities. Number two, you're not there to hold your company hostage with your own abilities. Building a product is a team effort amongst a group of engineers, not the brainchild of a single engineer. Number three, sometimes the most valuable thing you can do as an engineer is help unblock other engineers. Number four, the amount of code that you deliver in your next work session or within the next week is much less important than the sustainability and the pacing that the team experiences over the next couple of years. Number five, it takes more than just code to build a product. Collaboration and cooperation with your team is a core part of your job. And finally, number six, your work is not about you. It's about your relationships with others. I feel very strongly about these six ideas and there are certainly more. This isn't some kind of manifesto of what it means to be a force multiplier. This is a form of self-improvement. This is a form of self-improvement. This is a form of self-improvement. This is a form of self-improvement. This is a form of self-improvement. But instead, these are the ways that you can be thinking about your career long-term. Your productivity as an engineer shouldn't be based simply on the lines of code you deliver, the number of cards that you close out in your Jira or your Asana. It shouldn't be based on just simply shipping, but also how you empower the engineers around you. What is the sustainability and the culture of the team that you're building for the long-term? No matter where you are in your career, whether you are a young developer, maybe a mid-level, a senior developer, a mentor, a manager, it's incredibly important that you remember that your success in your career is going to be based on how you work with others. I hope that this episode has been encouraging to those of you who have felt a sense of uncertainty about your own contributions on your team. And I hope it's also been encouraging and enlightening to those of you who have kind of taken on this persona of the 10X engineer. And hopefully you can start to connect better with your peers and see your work in a different light. Thank you so much for listening to today's episode. Thank you again to Linode for sponsoring today's episode. You can build pretty much anything with Linode. Head over to linode.com slash developer T. You're going to get $20 worth of credit if you're a new customer. Today's episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.