Profile picture Schedule a Meeting
c a n d l a n d . n e t

On becoming a 10x engineer

Dusty Candland | | coding

I know, 10x engineer is click bait-y...

A 10x developer will have insights and find solutions that would never occur to an average programmer; they will avoid entire categories of problems that eat up enormous amounts of time amongst average programmers. 10 engineers writing the wrong code could definitely be out performed by a single engineer writing the right code. -- Yevgeniy Brikman The 10x developer is NOT a myth

Yevgeniy also says 10x developers are rare. I agree on both.

But, can you become a 10x engineer... or at least an 8 or 9x?

I don't know, but these traits will make you a better engineer.

Be a craftsman

Take pride in your work and constantly improve. Always be learning more about software and your tools.

Understand higher level concepts like design patterns, OOP, FP, common database structures. Learn other programming languages. Experiment and try new ways of doing something. Build an application in two styles or two different stacks.

Know your tools. Take the time to learn your editor, its shortcuts, and what it helps you do. Spend time on the command line and learn the tools available there. Use linters and formatters.

Take responsibility for your work and learn from your mistakes.

Be creative

Look for simple solutions. Simple solutions are quicker to develop. They're easier to understand and debug. And they cheaper to maintain. Adding constraints to a problem can help find simple solutions.

Think of different ways to solve a problem. Having a few potential solutions can help you think about the problem from different angles and spot problems you might not of found until later. It also gives you a plan B or C in case something makes plan A unusable.

Use metaphors in your projects. This helps others get a quick idea of what the code or project does. It also helps with naming, which we all know is the hardest part of programming! I forget where I found this, but I definitely like it.

Be a fixer

I was reading about consulting, and different roles that consults play. It's by Jonathan Stark, The Cab Ride. It's short, worth the read, and inspired this post.

Understand the why, the motivation for doing something. What is the actual goal, the expected outcome. Dig deeper.

Often, someone will propose a solution, but nothing says it's the best solution. You will have insights in the code that could result in a better solution, or a faster solution, but only if you ask and understand the goal.

View problems from another perspective. Be empathetic.

Be an enabler

Help others do their best work.

Mentor other developers. You'll learn something along the way and they'll become better. Which makes the whole team better. Pair with people when they're stuck, but try to help they figure it out, don't just do it for them. Review PRs with the intent of providing helpful feedback. It doesn't all need to be implemented / fixed in the PR, it can just be notes or related topics to check out.

Build tools that help the whole team. If there is a lot of boilerplate code, write a generator to create it. Look for things that are repetitive and automatable, then automate them.

Streamline processes and systems. Adding code linters to the CI process, for example. This saves time in PRs and leads to consistent code.

Take the shit work and let others push themselves. This helps the team grow and understand more of the codebase. Plus, it gives you an opportunity to fix or optimize the shit work.

The true 10x engineer by Bill Eager expands on this idea.

Don't be the brilliant asshole

Their contribution is limited, at best. They're detrimental as the team grows. They don't help others, they're not humble, and what ever personal productivity gains they have won't compensate for the damage they do the overall team.

Are you a 10x Programmer, or Just a Jerk?

Here are some other good posts I found while researching this.

Maybe you want to go the other way and Become a -10x engineer


These are webmentions via the IndieWeb and Mention this post from your site: