What Are the Implications of Being an Average Software Developer?

The problem with “average” is that it’s hard to quantify.

You can easily recognize the so-called “10x developers” (the A-players).
And it’s clear when someone is not made for the job, at all.

Organizations have a very hard time finding and headhunting rockstars (due to their rarity) and try to avoid poor developers. We can easily assume that the majority of almost every tech team is comprised of “average developers” (~70%).

Since this represents a large group with a broad set of skills or expertise, assessing where you stand on the chart is complicated.

  • Are you in the top 10% of the “average software developers” or the bottom 10%?
  • Are you a better programmer than most or not?
  • Does your team leader assign more complicated tasks or can they rely on you for those?
  • Do you adhere to your time frames? Are those longer or shorter than usual?
  • Can you compare your skillset with people with different ranges of experience – average juniors, mid-level, seniors?
  • Does your code require a lot of back-and-forth from QAs, managers, other peers?
  • Are you capable of handling work requiring R&D, heavy debugging, performance optimization, refactoring?

The list goes on.

Being unable to understand “how average” you are is dangerous.

  • If you are at the bottom of the list, you may be scheduled for the next group of layoffs – right after the poor developers.
  • Restructuring a team or losing a project leads to resource optimization – top players stay, others may be in danger again.
  • Hiring more experienced developers means that you’re slowly shifting to the bottom of the pool.
  • Hiring more motivated developers as well.
  • Being an average software developer often reflects on the chain of command. Hustlers may become your team leaders or project managers. This may result in a troublesome process affecting your work (or job).

“Average” may be “low” in other companies.

In the event of losing your job (or looking around), your personal assessment of “average” may result in other qualifications depending on the hiring process and requirements by other organizations.

If you’re working in a fast-paced high-tech startup that innovates a lot, being average probably means a highly experienced pro for most generic organizations.

But if you work in a traditional, slow, corporate environment where projects last forever, teams are comprised of dozens of developers, each sprint takes 6–9 months, you are probably not best suited for more rapidly evolving companies. They may rank you as non-qualified or even junior based on their standards.

I’m generalizing, but you get the gist.

That said, being “average” is overall fine. If your code quality is decent, your team is happy with your work and you learn something at work every now and then (progression), that shouldn’t be a problem.

There are certain risks for average developers. If you are fully aware of them and comfortable in the long run, you’re good to go.