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 Developer To dismiss this stereotype. But unfortunately, there is a similar stereotype that prevails in our industry of the TINX 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 Cutrell. I mean, 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 TINX 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 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 stereotype, some of the most common perceptions of what it means to be a so-called TINX engineer and why those things are actually probably harmful. The first characteristic is that TINX engineers relentlessly avoid doing anything that doesn't produce code. TINX 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 TINX 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 that will produce any real working code, so why waste your time on that. The TINX 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 TINX 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 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 the very least bottleneck. This person is 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 into some kind of documentation or into another person, all of that knowledge goes with them. And so what often ends up happening is the TINX 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 TINX 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 TINX engineers are insulated by the other engineers, the ones who are willing to take the time to document and share knowledge with each other. The characteristic of the TINX 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 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 TINX engineer, they have to sacrifice the things that they otherwise would be participating in. Another important characteristic of the label TINX engineer is that these engineers are typically working in the earliest phases of a given product. In other words, their 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 this initial kind of big sprint from a TINX 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 have comparatively more productivity than the next person. There's plenty of other characteristics of the TINX 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 learning side of things, 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 kind of 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 Tea. That's linode.com slash Developer Tea. All one word, use the code Developer Tea2019. That's the numbers. 2019 when you check out linode.com slash Developer Tea. Thanks again to linode for sponsoring today's episode. We've been talking about the label of Tenex engineer. If you've ever felt inferior because you don't think that you are one of these, you're not alone. Most engineers don't produce code like this Tenex engineer kind of person would and most don't want to. Researchers 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. What I would prefer for myself and for the people who listen to this show is to think about yourself as a force multiplier. Other than being 10 times 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, building a product is a team effort amongst a group of engineers, not the brain child 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. One, 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 multiplying engineer, 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 enlightening to those of you who have taken on this persona of the TenX 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 Tea. You're going to get $20 worth of credit if you're a new customer. Linode's episode was produced by Sarah Jackson, my name is Donna Finca-Troll, and until next time, enjoy your tea.