10x as an Individual Contributor
There's a thing I've been rethinking, lately. What does it mean to be a 10x programmer?
The first thing that comes to mind... programmers write code, right... So, a 10x programmer should write 10 times the code of their peers. Only, shipping more code doesn't make someone a better programmer.
I have made this longer than usual because I have not had time to make it shorter.
Everybody who's worked on a few projects knows that the simplest solution to a problem, while not necessarily the shortest, is generally shorter than the first solution. You can write 10 times the lines of your peers while completing 1/10th the features, if you're not careful and you don't refactor. Which leads us to the next possibility...
A 10x programmer obviously ships 10 times as many features as their peers. That rings a lot closer to the mark... Of course, we can go into the semantics of what constitutes a feature, but I digress. It feels pretty close, but I think we can do better. For one thing, if you build everything, how do you ever go on vacation... you've got to support the things you build (at least, at Amazon, we do). Even if you don't, when you go on vacation, your projects go on hold.
My manager has been telling me to be a force multiplier for years... I don't think I really understood how to do that, well, until very recently. I've been mentoring, taking part in hiring, onboarding, code reviewing... all the things I thought could help get me to be a force multiplier. I'm not sure any of this actually got me there, though.
You see, it's not a quick process, getting others to understand how to make complex code simpler, getting them to stop talking about how to implement a thing and start shipping features, getting people hired into the team, and onboarded quickly. Besides, eventually, they tend to move on, to other teams, to other positions, to other companies. Then all the force multiplying you've done, while it wasn't a bad thing, it's no longer helping your team move faster.
No, that's all good and important... it's important to grow your team, both in number of developers and strength of developers. However, I have recently come to the conclusion that it's not the best way to be a force multiplier while still being an individual contributor.
So, I think the key to being a force multiplier as an individual contributor is communication of your ideas and designs. You have to get the things out of your head... somehow. Writing them into code is one way, but it's not very fast, and you have debugging, and making it pretty and getting the design and functionality right. Those aren't the idea, those are details of the manifestation of the idea. While that's the end goal, if we add some steps between idea and code, we can get help getting to the end of our idea. If we can communicate, successfully, in a way that is as fleshed out as possible, without all the minutia and bogging down that writing code can (and will) get us, communicate our idea to others on our team... now, and in the future, we can get help writing the code. We can get help supporting the code.
The "Design Document" serves as a place to make decisions about how you will solve the different problems that coding your idea could present. It will generally list other ways to solve the problems as well as the reasons they were set aside. This design document allows your team to help you get your idea into code, going the direction you had envisioned. It also helps to break apart the idea into chunks that can be worked on individually.
The design document is a plain text file which explains the changes you are going to be making in English. It can (and probably should) have code samples, libraries, patterns... all the things we talk about when discussing our project with other engineers. Another engineer, with sufficient experience, should be able to read your document and build your idea, with little to no previous knowledge of the project.
For green field projects, creating the design document may seem easier, but I think it is actually harder to make a good design document for something that doesn't exist in any way, yet. There is a lot of different parts to think about... as well as how all of those parts work together. Flow charts, object diagrams, and workflow diagrams are tools that I find helpful in getting my ideas into a straight line.
For projects that are adding features or functionality to an existing product, I find walking through the existing code... making notes about where things are going to have to work differently is the most helpful in drawing up a design document. It kind of gives me a checklist (or list of stories / tasks), as well.
Now, the design document is only one piece of communication that you have available to share. I must admit, I am drunk on the Amazon Kool-Aid when it comes to working backwards. An internal press release is not only a great way to flesh out your ideas and work out just how they will benefit the customer, it's also a fantastic way to present your idea to others.
One thing I've learned over the years... if you don't write your ideas down or share them, they are far more likely to never see the light of day, and if you share them without writing them down, they are likely to become someone else's idea, at least if they are good. They may credit you for it, in some rudimentary way, but the idea will most likely warp, since you just shared it through auditory transfer, instead of writing it down somewhere it can be referenced.
So, there you have it. The way to be a force multiplier as an individual contributor, the way to truly get to be a 10x developer (as I currently see it). Is to write, not code, but prose. Write documents. Make it easy to help you. Get people excited about your ideas and make it easy for them to jump in and start helping you build them.
Published