Why It's Okay to Be an Ordinary Developer

Someone once asked me what it takes to become a prominent developer. A “10x engineer”. One of the “extraordinary” ones. My first question back was: what do you mean by extraordinary? I’ve had opinions on this for years, like most of us, but they’re much firmer now. And they apply to almost any career, not just software.

We only look at the far right of the bell curve

The industry has a polarisation problem. We stare at the far right tail of the bell curve and forget that most people, by definition, sit in the middle, and plenty sit below it.

Social media makes this worse. It’s easy to get swept up in stories about the top 1% of the top 1%, romanticised as the standard everyone should meet. Someone started programming on their dad’s Commodore 64 at age four, and you feel behind because you started at four plus N. Someone shipped a pile of apps and exited with millions while you were busy playing video games with friends. Someone is running a multinational company in their twenties. The list never ends, and the message underneath is always the same: if you’re not like them, you’re “just” average.

There is nothing wrong with being average. A big disclaimer, though: average is not the same as complacent. The “not even trying”, “come what may”, “I still can’t finish this module after five years” attitude is a different thing entirely. You know the type. Don’t be that person.

The “10x” label itself deserves more scepticism than it gets. It’s usually traced back to a 1968 Communications of the ACM paper by Sackman, Erikson and Grant, which reported very large differences between individual programmers. That study was mainly about online versus offline programming, and the often-quoted 28:1 gap came from comparing the best and worst performers in a group of only 12 experienced programmers, working under mixed tools and conditions. Critics have pointed out ever since that a best-versus-worst ratio from a sample that small says little about the typical gap between two developers on the same team. A half-century-old observation about variance turned into a hiring slogan.

The hiring and self-help machine

A lot of companies set unrealistic standards so they can claim to hire only “the top 5% of the world”. The pitch often continues: maybe you can intern with us for minimum wage or nothing, and if you wear multiple hats and work 90+ hours a week, maybe you’ll become extraordinary too. Maybe if you attend the right conferences, read 100+ technology books, and use only the command line and never a mouse.

You end up buying the idea that there’s a hero waiting inside you to be unleashed. Much of the self-help industry and some HR culture sell “feel good” training on exactly that premise. I don’t accept it. You don’t have to be extraordinary at work to be a good person, and you shouldn’t let a random book or article tell you you’re not good enough because you don’t set SMART goals every week.

I say this as someone who used to be part of the problem. A couple of years ago I was “that guy”. I’d look down on people who weren’t technical enough, who didn’t spend extreme hours learning technology X, who weren’t “as good as me”, and a whole list of other imaginary ceilings. I thought I was great. I wasn’t helping anyone.

Better questions: are you good to work with? Do the people around you learn from you and get better because you’re there?

Most performance metrics for developers are vanity metrics

How do you actually measure an “extraordinary” developer? Most attempts I’ve seen fall into the vanity metrics trap: we want a number to compare, so we grab whatever is easy to count. Some I’ve been measured on, or seen used, that I think are unjustified:

• Lines of code written. More code is often worse code.
• Number of passing unit tests. I can write hundreds of tests that prove nothing.
• Ratio of passing to failing builds. This rewards people who avoid risky but necessary changes.
• Number of commits. Easy to inflate, and it says nothing about value.
• Time spent “online” or in the office. Presence is not output.

It gets stranger when you join a company with an odd performance review process and these numbers decide your rating.

There are better signals, and none of them are new. Look at the outcomes someone helped deliver: the problem solved, the customer who stopped complaining, the system that stopped paging people at 2 AM. Look at how much their teammates grow. For delivery itself, the research in Accelerate (Forsgren, Humble and Kim, 2018) gave us four key metrics: deployment frequency, lead time for changes, change failure rate and time to restore service, which Google’s DORA team explains and shows how to measure. Be clear about what they are, though. They measure a team and its delivery system, and the moment you use them to rank individuals you’ve built another vanity metric.

The other comparison trap is status. Someone earns more than you. Someone gets a diamond plaque and you don’t. Someone has “Chief”, “Head of” or “Senior Lead Global Distinguished Architect Black Belt” on their profile while you’re still “Associate Junior Assistant Team Lead (Secondment)”.

Envy only makes sense as a full swap

You shouldn’t be jealous of that person. They’re unique, and they aren’t you. The test I use comes from Naval Ravikant, collected in the happiness part of The Almanack of Naval Ravikant (Eric Jorgenson, 2020): unless you’d take a “wholesale, 24/7, 100 percent swap” with that person, there’s no point being jealous.

You can’t cherry-pick their title or salary. You’d have to take their age, family history, struggles, failures, health, relationships and everything else, and give up everything you’ve built and everyone you love. If you’re not comfortable with that trade, let the envy go.

Ordinary is who we build for

At any company, you won’t always work with “extraordinary” people, and most people in the world aren’t. We design and build applications so that ordinary people can use them, get more done at work, and maybe make their lives a little more meaningful. The value of your work is the outcome it creates, not how complex the technology behind it is.

So the goal isn’t to become extraordinary. It’s to be a better developer than you were last year, and to stop feeling bad because you’re not in someone else’s highlight reel.

There is more to life than code

There is more to life than code, for 99.99% of us anyway. If you’re in the 0.01% who wants nothing else, and you’re happy and healthy, that’s okay too.

Don’t feel guilty if your GitHub contribution graph isn’t solid green. Don’t feel bad if you don’t wake up at 5:30 AM. Interests and priorities change, and that’s fine. Maybe you’re deep into programming today and in five years you decide to become a bee farmer. Live your own life.

If you’re struggling with your career or your life right now, message me on LinkedIn. I’m willing to listen.