10x Developers Are Good at These 3 Things, and You Can Be Too
10x Developers Are Good at These 3 Things, and You Can Be Too
A 10x developer quickly knows what they need to do, what questions to ask when they don't, and are masters of juggling priorities.
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
Nearly every software developer or programmer has encountered code written by someone else that proves the cliché “anyone can code.” But have you ever encountered the supposedly mythical “10x Developer?” Being a 10x developer has less to do with excelling at writing code and more to do with knowing exactly what code to write.
Many of us began programming for a specific purpose. For example, I started writing code to autoplay text-based MUD games for me while I was sleeping and at school. I was a script kiddie at 13 and didn’t even know it. I could come up with an idea, write the code, and test it — all by myself.
Software development is hard when we’re doing it for someone else because we often lack the same type of motivation and excitement that drives us when we’re pursuing our own vision. We don’t come up with the ideas, we spend hours in meetings trying to understand them, and then we spend most of the time modifying someone else’s code — or at least contributing to it. That can lead to a level of detachment that lessens productivity.
To be a 10x developer, you have to learn to excel in this environment or even start your own company to lead the charge.
Anyone can be a 10x developer, at least for part of the day, every day. I believe that there are three things that all developers should focus on to become more productive and a better team member.
The 3 Things
To be a 10x developer, you need several years of experience working with whatever programming language and toolset you use. You have to be good at solving problems and writing code; this is a given.
It’s important to understand that how you write code isn’t what makes you a 10x developer, 10x engineer, 10x programmer, or whatever you want to call it.
You know the 5 Ws: “Who, what, where, why, when.” While these all apply to software development, I want to focus on the three characteristics that define 10x developers. These three things differentiate the average developer from the 10x developer:
Knowing the What
In the corporate world, developers tend to work on projects they don’t have much passion for and don’t understand. For most developers, this isn’t a big problem, as long as they receive very good directions and expectations are clearly defined.
The problem is that developers usually are not given adequate instructions. Instead, we use this thing called “Agile development.” We get a Post-it note with a few words on it and are expected to know exactly what needs to be done.
Software development is all about communication. Developers need to know what we’re working on, what problems we’re trying to solve, and exactly what the result needs to look like. The more we know up front, the faster we can go. Most importantly, knowing the intent of the work and what will make the work a success is crucial.
Bad developers will spend hours going the wrong direction on a project without asking any questions. They’re what I call -10x developers because they get nothing accomplished and waste the time of all of their coworkers. Nearly everyone has encountered some of these developers, and it can be frustrating to work alongside them. And you must be careful not to pick up their habits!
Some developers work well even without a lot of details. They use a great amount of creativity and ask the right questions. These unicorns are likely 10x developers. They know how to figure things out and often lift up the level of the entire team working around them.
The bottom line is that 10x developers are really good at quickly determining what needs to be accomplished and what questions to ask.
Understanding the Why
Perhaps software development’s biggest obstacle is understanding the why. If you don’t understand the problem you’re trying to solve, it’s really hard to solve it.
Why was I hacking terminal scripts together to play my MUD game while I slept and was at school? I wanted to attain the highest level in the game, of course. I knew exactly why, and I was doing everything I could to make it happen.
The same approach applies to any software development project. Developers who understand the industry vertical they’re in and the problems they’re trying to solve will be much more productive. Knowing why and understanding the vertical also helps prevent unnecessary work, freeing up time to focus on the things that will make a product or feature more valuable for users.
The problem is that knowing why isn’t good enough. You have to have a passion for the problem and understand it inside and out to truly be a 10x developer. I believe that most 10x developers are also product people at heart, endowed with good product vision.
Knowing When to Do What
Timing is important for software development projects. Picking what order to work on items in your back log is a seemingly easy task that is really critical. Do you work on something that can help your company land a new account or go clean up old technical debt?
As development teams, we have to constantly juggle what we work on and when we work on it.
All software development work items fall into these three categories:
- Things we have to do
- Things we need to do
- Things we want to do
We have to get this new feature done for a client. We need to fix bugs in our software. We want to work on technical debt or some cool new product feature. It’s always a balancing act.
We should be doing work items from all three of these buckets concurrently. We can’t spend all of our time on technical debt, but perhaps we should spend a small percentage of our time on it.
Developers also have to know when to build complex architectures within their code. I prefer to keep the code as simple as possible until I’m forced to add architecture that I can’t otherwise live without.
Developers also have to know when to avoid chasing shiny objects. They tend to want to play with new tools and technologies, but these solutions may only slow down a project rather than help get it done faster.
10x developers are good at juggling priorities and understand when to invest time into architectures versus slinging spaghetti code to make something work. Remember, your users don’t care how your software works or how fancy the architecture is. They just want it to work. 10x developers understand this.
Mastering the What, Why, When to Become a 10x Developer
Now let’s talk about how you can master the important skills of What, Why, and When to become a 10x developer.
Start With Why
The first step to becoming a 10x developer is becoming passionate about the software and problems that you’re trying to solve. You need to understand the problem inside and out. That starts with being enthusiastic about the company you work for and their mission as a company.
Don’t just make a button do something because that’s what someone said to do. Strive to understand why at a higher level. You will be much more valuable to your team and company if you remain focused on the why.
Be a Good Developer and an Excellent Problem Solver, Not the Best Programmer
I would describe myself as more of a hacker-developer. I’m the type who can sling some ugly code together to solve almost any problem very quickly. My code is rarely beautiful, but it works. And that’s what matters.
You don’t have to write perfectly architected code with unit tests to be a 10x developer. You need to know when and when not to do those things to be a 10x developer.
A 10x developer is good at solving specific problems and satisfying the business needs with code. The smartest thing you can do is know how far to take a project before you hand it off to someone else who may be better at finalizing some of the architecture and other little details.
The When Is in Your Gut, or It Isn’t
Knowing when to build out a complex architecture versus hacking something together comes with experience and the development of your spidey senses. You either have that gut feeling or you don’t.
Some of the smartest developers I have ever worked with have been the worst at prioritizing patterns and architectures over functionality and schedules. They wanted to over-engineer and rewrite things over and over, striving for “perfect code” rather than “shippable code.”
10x developers have to use their experience and gut instincts to know when to focus on architecture and perfection versus getting shit done.
Know What to Do and What to Ask
So much of software development comes down to communication skills. Sadly, many of the notes and requirements we get for work items are not very detailed. A 10x developer knows how to read these, apply the “why” that they know about the business and ask relevant questions.
The best developers know how much time to spend on something before they ask for help. They also know what questions to ask to clarify what needs to be done to move the project forward.
I have been writing code for more than 15 years. I would say that I am a 10x developer, or at least I can be. I know what I’m good at it. When I’m doing the things I’m good at, I can get a serious amount of work done quickly.
If you want to prototype a new product, I’m your guy. If you need help with Angular, React or some other front-end development, I am most definitely not your guy. I would be a -10x developer at those tasks.
10x developers are not a myth. They do exist. They are most likely dev managers, architects, lead developers or company founders. If they aren’t, they probably should be. I ended up being a company founder, twice now.
Also, nobody is going to be a 10x developer every day, all day long. We don’t have the energy or focus for working at that pace every day. We’re not robots.
If you understand the “what, why, and when” of software development, you can be more productive and a better team member — perhaps even a 10x developer for a few hours a day. And that can make a big difference.
Published at DZone with permission of Matt Watson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.