The Mythological 10x Developer
One of the first things you learn as a professional software developer is just how difficult it is to quantify your performance.
There is no developer equivalent of a running a four minute mile, proving ourselves capable for good.
Worse, the difference between trained runner’s times for a mile isn’t a multiple of 10.
This lack of transparency about our true “performance” can lead a lot of people to feel like frauds, and lead to suffering from impostor syndrome, limiting contributions to the community and growth.
And yet, in our field the idea of 10x developers persists. People who manage to achieve 10x the output of a trained developer.
This developer can build tools that unlock productivity multiples for hundreds thousands of developers.
By zooming out on problems, they add something like a 1.05x increase distributed to others and cause huge shifts in the way we all work.
For example, a person writing Linux, OpenFrameworks, Git, Python, PostgreSQL, emacs, etc. ends up creating tools that are a multipliers for the developer community as a whole. Their efforts allow everyone else to use those tools as new layers upon which to build things.
In actuality, these developer’s output goes far beyond a multiple of 10x, because they build new tools for solving problems.
Sometimes, they even manage to create things that weren’t possible before, like the advances in convolutional neural networks and computer vision that now allow us to do object recognition so well.
Reaching for an Achievable 10x
But notice building these tools also requires a bit of luck.
They require an environment where some of the value of the gains in productivity can be captured for sustained development. (And let’s face it, some of these people are just insanely talented!)
For the rest of us, we don’t have a chance to write the high impact tools and libraries that unlock these huge gains for other people. We’re just too busy solving mostly boring problems for businesses and getting paid.
The best we can do is bend our environment and ourselves slightly for the better and hope to generate a 10x difference in productivity over time.
For me, the chart of productivity over my career isn’t a linear scale up and to the right. Or even a hockey puck up and to the right.
Or even consistent. And I doubt I’ve really achieved a 10x of a normal developer, ever.
Instead, it’s been choppy, and largely dependent on the organizational environment and incentives I’ve had around me:
Today I’ll walk through the things that have affected my development performance in multiples, cumulatively adding up to at least a 10x difference from the lowest point (well below 1x) in productivity for myself.
I hope you’ll reflect on your own performance, and start thinking about ways in which you can multiple your efforts for yourself and your team.
(Even when you’re not in an ideal environment.)
What do developers really do anyways?
Writing new code isn’t the primary focus of our job.
Instead, the majority of time we spend as developers is spent reading other people’s code, and thinking about how to fit that into the problem we need to solve.
…and then we think about how the problem being solved a certain way affects the rest of the existing code, people, and processes.
In order to be a 10x developer, you have to build context about what you’re working on. That means taking a step back from work to ensure the overall effectiveness of their efforts.
So 10x developers constantly ask questions like:
Should I be building this? Or can this be accomplished an easier way?
Is this really the best way to get to what we want? How will this effect the rest of my team? And what about their morale?
How does this solution work longer term?
A 10x software developer is, by their very nature, aware of all the things outside of the code itself that contribute to the effectiveness of the code they write.
Usually, people assume that 10x developers get there by chance. That they’re just much smarter than everyone else.
But the only real measuring stick we’re going to use is ourselves, and improving our current level of performance.
Read Other People’s Code
The most important thing you can do is to begin the practice of really reading other people’s code.
There is just tons of code waiting on Github, ready for you to learn from.
Some of it will be terrible! Most of it will be mediocre. But reading how other people solve similar problems gives you perspective.
So, when you’re working on a new API, just go start perusing the API documentation, and once you’ve done that enough to grasp the overall structure, jump into the code itself.
You’ll learn patterns for how other people, just like you, solve problems over time.
It’s the developer equivalent of being able to read other people’s minds. If their code is bad, how would you solve it? What’s the minimum effort to improve the code?
Reading other people’s code gives you ideas for how other languages beyond your chosen language may solve different problems better. It also jars you into thinking outside of your solution patterns you’ve applied over and over.
My favorite side effect of reading the source code is eliminating mythology around code. You shouldn’t ever have to guess about what code is doing. Go read it!
And Github’s code search is really good now. Use it!
Accept Responsibility for Your Performance Over Time
Are you 10x one of your previous selves? It’s so weird to try to quantify your own output.
In a linear model, and in an organization that revolves around the number of JIRA tickets closed, the question itself seems absurd.
How could a person accomplish 10x more tickets per week of development? And why would they want to?
It’s your responsibility to stay away from this linear sort of thinking.
When you start focusing on larger gains, you realize learning the latest API, or library isn’t the problem.
The problems we face mostly tend to be around the way we work with other people, and the incentives at the places we work.
If you work in an open office, with people constantly moving around you, and have no opportunity to do focused work without interruption for more than 10 minutes at a time, you can easily become .5x or less your normal self.
And if you have no say in your work, are handed a number of tickets to fix bi-weekly, your motivation can go down even further.
Have a boss or manager who’s a bully? Multiply that .5x by another hypothetical .5x. You’re down to 1/4 of your potential.
Worse still, you can be pushing yourself to burnout, effectively going net negative in your output, as you add downtime you’ll need to mentally recover from stress.
Choose the Right Games to Play
I can remember distinctly the moment in my schooling when I realized much of high school wasn’t really about an education.
Similarly, much of what we do at work isn’t really about the software we’re developing. I’ve seen so many instances of expensive developer time and mindshare being wasted by organizations that refuse to listen.
You may just end up at a company where politics have taken over. The software product may not actually matter organization, may just be viewed as a cost center, or it can be a power grab amongst different departments.
In this case you’ve got to take things into your own hands, and become aware. A 10x developer is aware of their political surroundings, and knows when their efforts are being sabotaged.
They make plans to save and get out.
Getting out from a bad organization or boss can make you an instant 10x developer alone, compared to your current output.
Learn Another Programming Language
Spending time to understand different language paradigms people talk about is worth while.
A functional lisp, low level language, or a higher level language, allows you to understand how the same problems you face while designing your programs can be approached in different ways.
Having spent time writing Clojure and NodeJS, the way I write my Python code has completely changed. I try to keep everything in functions where ever possible, steer away from Objects, and pass back as simple of data structures as I can.
Aesthetically, that functional approach resonates with me, and tends to be the way I like to solve problems.
You might find something else resonates with you. That’s where you start to build an appreciation for the things you write.
Having an appreciation for what you think is ‘elegant’ allows you to start making decisions about how to approach problems. Each new language you learn gives you just a tiny bit wider of a perspective.
It also adds to your enjoyment of writing code. Which, if you’re aiming to improve yourself by a multiple of 10, is something you’ll be doing a lot of.
Learn to Communicate Effectively
For developers, communication is everything.
Software development is:
0) understanding the problem fully
1) understanding the previous person’s thoughts in code
2) clarifying your thoughts and finding a solution in logic, then code
3) converting your clarified thoughts back into code
4) cleaning up behind yourself for the next person
That’s it.
Learning to write well, to defend an opinion, to be wrong, all these things unlock new possibilities for the code you write.
As much as we want to believe in the perfect code spreading like wildfire, we first need to communicate the value of our time and code. And we do that by valuing the other person’s time.
There are plenty of books on writing. Stephen King’s On Writing and William Zinsser’s Writing Well will get you 80% of the way there for 20% of the effort. Start there.
Use the Right Tools for The Problem
Sometimes in software development, it seems as if people choose more complex solutions for terrible reasons.
Moving to micro services and Kubernetes with a team of two people, adding react and a million javascript dependencies, until we’ve got more tools than actual code in our projects.
Being able to know when a tool is appropriate is an art. You need to fully understand the tool, and fully understand the social implications of how the team will interact with that tool.
Things like Kubernetes and micro services are solving problems that mostly larger organizations have.
They need to have a lot of developers pushing changes to code at the same time, without having to coordinate everything. They can afford to have a dedicated team building software development tools to abstract away some of the complexity.
That may or may not be useful to you. Learning a tool while thinking of this sort of social context gives you the ability to make better decisions.
Learn to Work as A Team, and Work with Good People
Software development is like writing. There is nobody else who is going to do the work for you. You need to do it all yourself.
In On Writing, Stephen King calls writing a first draft “closed door work”. You need to make things alone, to have the pure focus needed to make anything new. It’s a very delicate proposition making anything new, and it needs to happen in a place free of judgement first.
But once you’ve written your first piece, and polished it a bit, it needs to see the air of day. So you need to share and communicate your changes, in a way that lets other people who’s feedback you value judge it.
And the team part of software development is much more difficult and subtle than most any other sort of teamwork you’ll run into. It’s about communicating with other people to understand their tradeoffs, and why they’re doing things in their ways.
Understanding the other person’s feelings, incentives, and perspectives allows you to build multiplicative work, and allows you to see places where a little boost can add another .1x to their efforts.
Spread across a team, even just being a cheerleader for people, being proud of their efforts, can make you into a net 10x developer for the rest of the team.
Not everything is purely technical! We’re still all still humans!
(For now.)
Study Your Ass Off & Stay Healthy
There is no free lunch.
You have to actually do the work. Day in and day out. For a very long time.
And even when you do the work well, things might not work out. Your work over years might get thrown away.
Outcomes aren’t the only thing. Put in the work, and evaluate your own performance. Learning to enjoy the process of solving problems sets you up to stop caring about outcomes anyways.
Eventually, hard work will hit the slot machine of luck, and you’ll get a good outcome.
Don’t stop, keep going. But do so in a sustainable way.
Eat well, sleep plenty, get exercise, and treat the people around you well.
Value the User’s Time and Mind
As a community, developers have gotten better at this. We largely understand that the smallest of changes can have lasting effects on the quality of life for our users.
For example, early Instagram.
For those not familiar, a good portion of Instagram’s initial popularity was due to two features:
Filters, which allowed people to pre-apply enhancements to photos, making them look much better. Speed, letting people post images in under a minute.
These two, seemingly minor things stacked together allowed everyone with a cell phone to become an amateur photographer. Overnight, billions of people started thinking through their daily experiences, looking for moments to share with their friends.
It was the dedication to making things easier for the end user that allowed for the bigger growth compared to a multitude of competitors.
The app got out of the user’s way, and let them directly share moments with their friends in the simplest possible way.
Critically Evaluate the Incentives Around You
Why do the largest tech companies evaluate potential hires the way they do? Why do they continue even if it’s apparent they’re excluding a very large and talented portion of the candidate pool?
Why do some companies insist upon working in an open office? Why do others pay such a large portion of their compensation in RSUs?
Thinking critically about the underlying reasons behind behaviors will give you insight into the true incentives of companies and their politics.
Putting yourself in a position to be a contributor to the growth of a company is usually the strongest place you can be.
Living within a largely political organization and trying to be a strong contributor is the worst. You run yourself into the ground working, and the product quality outcomes don’t matter to leadership at all.
Instead, they’re looking for cost cuts, respect for seniority, and unquestioning loyalty.
Don’t get stuck here.
Write Quality Git Commit Messages
For the overwhelming majority of my career, I never thought much about git commit messages.
Adding messages seemed like an unnecessary overhead. Just putting in “blah” or “changes” seemed sufficient enough, so I could push another change out for quick testing.
But imagine you’re walking up to your dream house being constructed. It’s behind schedule, and you’re going over budget.
Panicked, you ask the foreman, what’s been happening the past few days.
He opens up his journal of things he’s been doing or supervising, and you see:
April 3rd: changes
April 4th: updates
April 6th: bleh
April 10th: revert changes
What?!
Good commit messages tell the story of what you’ve been doing, and provide clues so the people who come after you have context about why things were done the way they were.
If you’re writing commits like above, think through what you’re doing. Try to explain it.
Rethink how you’re developing, and work in tiny, explainable chunks.
Promote Yourself
We love to pretend software development is a pure meritocracy, but it’s not.
Having a name people recognize, or having written a piece of software others use improves your chances of not being stuck in a bad organization. And as we’ve seen before, landing the right organization, and the right political environment is essential to doing your best work.
Everyone wants to work with great people, and great people create artifacts of their great work. Sharing these artifacts and sharing lessons learned with other people freely shows the value you can contribute to a team. It also shows you’ve actually done things.
Apply to speak at a conference. Write a blog post about something small and dumb you did that took more time than it should have. If you don’t have the time to set up your own site, try something like dev.to.
Spend Less than You Earn
Large sign on bonuses, stock vesting schedules, and high salaries exist for a reason.
They’re there to incentivize you into sticking around long enough to become a net positive to the organization you join.
If you’re unlucky, these sign on bonuses and high salaries can turn into traps. They become large amounts to pay back or walk away from when you need to leave a bad situation.
Especially for people who don’t come from at least middle class backgrounds, suddenly making decent money can feel surreal. You can’t tell how rich you really are, or what you can afford at all.
Spend less than you earn. There is no stronger negotiating tactic than being able to walk away from a deal.
Our software development salaries can seem high, but cost of living and the level of dedication necessary to maintain performance are also high. Don’t sell yourself short, and don’t allow your spending to outpace your earnings.
With a healthy savings and low costs, you’re empowered to walk away when a situations turn for the worse.
And, if you’ve been promoting yourself and treating other people well, you’ll have an easier time finding the next place to dedicate your work and your multiplier effects.
My Personal Journey
My current job as a developer advocate means I get to spend my time trying to be a multiplier for other developers.
A normal day is spent looking for things that are confusing or wrong about our product, chatting with customers, and working to make things better for everyone.
The company I work for (Datadog) has some of the most talented, compassionate people I’ve ever worked with. My manager goes above and beyond to ensure I have what I need, and is one of the best I’ve ever had.
If there is a limitation to my current performance, it isn’t the environment, or the place I work. Instead, it’s me.
Two years ago, this wasn’t the case.
I was working for a company I dreaded going to, with a manager who seemed to have it out for me, and with a decent sized signing bonus to pay back in order to walk away.
In other words, I felt stuck. This lead to worse output from me, and when I look at my productivity over time, this feels like a lost year.
I hope this post helps you avoid getting into a similarly bad situation. And if you’re in a similarly bad one, I hope some of the suggestions help you in planning to get out.
If you’re interested in working at what I consider to be a great company, Datadog is hiring. Feel free to reach out to me via a Twitter DM (should be publicly open), and we can chat first and see if it might be a fit.
