10x Developer – Devs Are Not the Same, Embrace That

Introduction

What is not widely known outside the software industry is that the differences between the efficiency of developers lies not in single percent but in hundreds or possibly thousands of percent.

A ten times developer is the developer who is ten times more efficient than the average developer on a team.

Of course it can be five times, it can be twenty times, but still – we’ll talk about the huge gap between developers on the same team.

How do we deal efficiently with this disparity in individual performance? How do we make the most of the ten times developers and avoid the common pitfalls?

It is usually not reflected in project estimates, as the cost, to my surprise, is not widely recognized outside of the people who are actually doing the software work.

So let me share my observations based on the thousands of developers I’ve met in my professional life, including many ten times developers who were among them.

Plus, ten times developers are recognized as anti-pattern by some industry analysts, so we will address this fact as well.

Pros

Really fast and high quality software

The pros are clearly visible. Ten times developers understand the requirements faster, ask good questions and then implement the components very quickly and with a very high quality standard.

→ Explore Avenga Quality Assurance Expertise

Productivity masters

Ten times developers are also lauded for knowing many productivity techniques including thousands of keyboard software shortcuts, tiny but useful tools, and other productivity boosters as well as configuring IDE environments really well.

They are also famous for knowing when to stop optimizing a toolkit and to do the actual work; where the line is between obsessive automation and actual development work.

There are systems where 80% of the codebase is created by 10% of the team!

And . . . this does not mean that the team was too big, as the remaining 20% is still critical for the system to run properly.

Cons

Here comes the boredom

Despite the usual hype about innovation and tech revolution, software products consist of thousands of relatively easy and boring pieces (components) that are combined together.

→ Read more about  Chatting about the future of AI with . . . the GPT-3 driven AI

Plus the core technology changes slowly, and sometimes there are even circles when the new idea is being replaced by an old idea, or . . . an even older idea.

There are moments which require very complex and unique algorithms. They have really specific unusual requirements that are not addressed by the open source framework of choice and have specific platform components on top of the frameworks.

Then ten times developers are more interested and focused, which is what they were trained for.

Impatience

It’s a myth that ten times developers are always bad team players. I know many who are very good mentors to the less skilled developers.

Of course, the negative examples of them showing a lack of respect and even being insulting are usually louder and easier to remember.

I consider this myth as something that hurts the majority of ten times developers.

Internal ‘vendor’ lock-in

It’s quite common that entire complex projects may depend upon one or two ten times developers who are so far away from the rest of the team that the regular developers are not even trying to catch up.

They code faster, know the code base better, and know the business requirements better. So far, far, away from the rest.

They can build internal silos . . . and often because of this, they consider themselves irreplaceable, can blackmail management, ask for more money, etc.

Weak management will let that happen, as they are full of fear and ironically are actually themselves being managed by the ten times developers.

Antipattern?

Expectations of agile teams of (equal) peers are harder to meet with ten times developers. People are not the same and they have different skills, however they should be treated with equal respect.

The assumption of ‘equal’ people in the team is wrong from the get go.

There’s nothing wrong with being ten times more effective than others. I disagree with calling ten times developers an antipattern.

Technical and project leaders should avoid the myths first of all, and remember that people are not the same and they won’t behave the same way in different situations.

Tips

It’s impossible to write a manual about these people, for the reasons mentioned above (and many more), but I’d like to share some tips.

First – a particular person may appear to be a ten times developer but they are not.  Actually, if they are creating code fast but with poor quality and it is hard to read by the others or even full of logical bugs, they are not a 10x performance increase at all. So, first of all make sure the person is really a productivity master.

Second – don’t assume and believe the myths. Ten times developers don’t have to be bad team players nor good mentors. It also depends on you, the rest of the team and the project context. Do not judge prematurely.

Third – it’s easy to convert a ten times developer into a poor leader of an extraordinary development team, thus losing their productivity and increasing their frustration.

Fourth – if you can convince and encourage ten times developers to share their productivity secrets and skills in a friendly way, you can expect an overall improvement of the effectiveness of the product team. The ultra developer could even be interested in shifting their role more to a mentor then to a team leader.

If you let them become internal lock-ins, you are in trouble and the cure for the problem will hurt; either letting the lock-in become stronger or removing the ten times developer from the team, both will impact your project.

I hope you enjoyed the article and are more aware of this phenomenon and how to work with 10x developers.

Avenga experts talk

How to work with 10x developers – what are your tips?

Roland Guelle – VP of technology at Avenga

In most of the commercial projects these “Rock Stars” are not really needed. The client wants continuous performance, predictability and quality.

Remember the Boy Scouts’ hiking story from “The Goal” with Herbie? 10x developers can reduce and increase the throughput of your team, depending upon their role. Instead of applying new frameworks regularly, their speed is pure gold when analyzing bug requests or doing merge requests.

In addition to this, these people love to do R&D or work with new technologies. At Avenga, we have our two special departments, R&D and Avenga Labs, specifically for this reason. Our delivery team engineers are able to ‘leave the trail’ and do something extraordinary (outside the commercial project) and share their knowledge with the whole team.