When 10X translates into -10X: debunking the myth of the 10X technical coder/writer
- Recent Command Line Heroes podcast on 10X
- The 10X Myth
- Parallels to 10X writing
- Toxic 10X personalities
- Understanding how we arrived at our level
- Growth-mindset perspectives
Recent Command Line Heroes podcast on 10X
One of my favorite podcasts is Command Line Heroes by Red Hat. In season 5, episode 3, What Kind of Coder Will You Become? the hosts pick apart the myth of the 10X technical writer.
This episode prompted me to rethink a post I wrote a while back called How to become a 10X technical writer in the workplace, which received a lot of clicks. (Side note: I actually don’t have any substantial 10X productivity tips in that post, unfortunately. My best productivity tip is here: Writing productivity tip: Focus sessions — the tip to achieve productivity is to simply spend 4 hours a day writing docs.)
The 10X Myth
The Command Line Heroes hosts explain the mythical idea of a brilliant engineer who codes a landscape-changing program like Photoshop or PayPal or BASIC in a short amount of time, working independently. The programmer taps into a creative flow as the code just rolls from fingertips to keyboard to screen and compiles.
Removing the other engineers actually frees up the 10X engineer to work more productively, as he or she can quickly make decisions, act more efficiently, and keep the whole program’s context in mind without passing through layers of bureaucracy and stifling review. Having too many developers on a team is like having too many cooks in the kitchen — they just get in the way of each other and paradoxically slow down the work.
Clive Thompson, the co-host for this episode and author of Coders: The Making of a New Tribe and the Remaking of the World, says, “… 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.”
Parallels to 10X writing
Although the hosts don’t mention parallels to writing, the same myth is common with writers. For example, consider the story about how Jack Kerouac wrote On the Road (one of my favorite novels):
The legend behind the writing of Jack Kerouac’s On the Road is well known, if not entirely accurate. Fueled by inspiration, coffee and Benzedrine, Kerouac sat down at his typewriter and — in one burst of creative energy — wrote the novel that would make him the voice of his generation in just 20 days, typing it out on a single, 120-foot-long scroll. (Kerouac’s ‘On the Road’ Manuscript Unfurled)
The reality behind Kerouac’s novel is less mythic, with much groundwork already laid and many rewrites, etc. But as writers, many of us experience moments when ideas just flow and we can craft a nearly perfect piece of content in a short amount of time. Sometimes an idea materializes in your head, you catch a vision, and a few hours (or weeks) later, you’ve created a short masterpiece. The same goes with coding.
Toxic 10X personalities
Although the idea of a 10X coder seems ideal, the Command Line Heroes episode actually flips the script and highlights the negative results of 10X coders. The 10X coder can be proprietary, entitled, arrogant, selfish, and sloppy. These types might lack patience in explaining anything to lesser mortals; they often want to do it all themselves. They are frequently assholes who are toxic to the teams they’re on.
The Command Line Heroes hosts tell a story about a coder named Rick who had become extremely proprietary about a large part of the code base. Another teammate made a commit, and Rick reverted the commit. One of the guests explains:
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 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 10X coder (Rick) pushes out a lot of code, for sure, but in this case, it was full of bugs. Others ended up fixing it for years afterward due to the technical debt. Saron Yitbarek (host of the show) asks Clive, “What’s the consensus about 10X coders?” He says,
I’ve 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 there’ll be like, “Look, I’m amazing and I generate a ton of stuff and I get the prototype done. But you know, it’s going to be a bit of a mess because I’m just working so fast and so intensely.”
The hosts seem to conclude that in ideal situations, coders can also uplift other teammates in 10X ways, arguing that 10X isn’t just an idea applied to writing code. Even a 2X coder who has a 1X impact on 10 teammates around him or her has magnitudes more influence than a 10X coder.
Understanding how we arrived at our level
The 10X discussion is interesting because honestly, I hadn’t realized that 10X could be a negative. The more I thought about it, the more I began to see how problematic the role is. However, I think at the heart of the problem is the mistaken belief in the 10Xer’s mind that he or she possesses some native talent rather than an ability cultivated through years of experience, practice, and learning.
For example, suppose you’re a senior technical writer on your team (maybe even a 10Xer in your mind), and you notice that you seem to finish projects faster than others. You look at the commit log, and it seems like your name appears way more often than other team members’ names. Others on your team seem to have trouble with tools, they break the build, they run into walls of silence with product managers, engineers won’t review their docs, and their projects blow up on them. Meanwhile, you’re batting home runs on each of your projects and development teams love you. Your docs get more hits than any others as well.
In this case, it would be easy to fall into the trap of thinking that everyone around you is incompetent. It would be easy to want to have total autonomy and control over projects, working siloed from others. But this can lead to a toxic attitude that stifles team morale and productivity.
To step outside of this mindset, you just have to remember a few details. How long have you been at your company? What was your training before your current role? How many years have you been writing? How many hours have you put into learning or developing the toolset? What’s your history with the projects you’re working on? How many interactions have you already had with these PMs and engineers?
For example, I’ve been at my current company 4.5 years and am entirely familiar with the products, people, workflows, and expectations. I built our team’s Jekyll theme and designed the publishing workflow, so of course troubleshooting tools issues and broken builds would come naturally for me. I’ve had many meetings with field engineers and PMs, and they know me, so it’s natural that they wouldn’t ignore me when I reach out to them. I’ve been a professional tech writer for 16 years, a marketing copywriter and writing teacher before that, and also earned a BA degree in English and MFA in creative writing prior to that. I’ve written hundreds of blog posts where I’ve shaped scrambled ideas into coherent narratives, so it’s natural that I would be comfortable on the keyboard starting from a blank page.
Take all of this away, and my productivity goes with it. One experience in particular cements this idea. One of my first projects at Amazon was to document Fire App Builder, a starter Android project for building Fire TV apps. I was totally new to the process of wirelessly connecting to Fire TV through adb (Android Debug Bridge), and even how to open up projects in Android Studio. I didn’t know how to run apps from Android Studio onto a Fire TV device, or even how to get the project source code from engineers. All of this was new. So for the first week when I started documenting Fire App Builder, I literally spent three days trying to get the app to build on Fire TV. Now, after 4.5 years of doing this, I can connect an app to Fire TV in under a minute.
We had a new tech writer join our team recently, and as he has been going through this same process, it has returned memories of my first days working with the technology. Remembering this makes me rethink whether I am a 10X technical writer (maybe more like 2X), or whether I’m simply more familiar with certain technologies and documentation. Most of my projects are now version upgrades from previous documentation that I worked on. It’s no surprise that I find it easier to get going in productive ways and finish in half the time as another colleague who doesn’t have this background.
I do think, however, that blogging here for the past 14 years has helped me develop my writing skills in helpful ways. I know the shape of a blog post. I know how to interweave quotes with commentary. I know how to focus on an argument or idea. This has helped me in writing documentation as well. Many others have spent time writing fiction or working on other writing projects that have led to similar benefits. But wipe away these years of experience with writing, and chances are we’d be on the same plane as many non-writers who are faced with a blank page and feel stuck, needing a detailed template or some other guidance.
Growth-mindset perspectives
The idea of looking past natural talent and instead acknowledging the hard work required to develop a skill isn’t a new idea. This is the same growth-mindset philosophy from Carol Dewicki heavily promoted in schools these days. In our family, when we talk about math with our kids, we’ve long dropped the idea that someone is good or bad in math, as it leads people to embrace a mentality that if they don’t understand something hard, it must be due to some innate lack of ability in that subject area. The reality is that most people who are good at math put in a lot of study and practice time with the subject, and perhaps their enjoyment of it leads to even more practice, and so on.
Recognizing the growth mindset not only helps us avoid the toxic 10Xer mentality of seeing everyone around us as less competent, the growth mindset also opens doors in new areas. For example, programming. Many of us might have taken a few programming tutorials and concluded that we just aren’t cut out for this area, or that our minds don’t work that way. Instead, if we unpack the many long hours of study, practice, trial and error, experimentation, and other training that developers put into learning programming, we might not be so quick to conclude that we lack an innate ability. Instead, we can feel empowered to achieve mastery in difficult areas if we put in the time and hard work to learn it. At the same time, we shouldn’t expect to just “get it” without putting in the time.
In summary, acknowledging the reasons behind our abilities helps us avoid a 10Xer toxic arrogance while also opening doors to skills we might not yet possess.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.