What’s a high-differential developer

The so-called A players, are they real?

I still remember an interview almost ten years ago, where the interviewer asked about my previous job. I listed a few projects I’ve completed during the six months I spent at that company, and the interviewer was quite impressed by the number of projects. I honestly didn’t think it was such a big deal (albeit it did feel nice to get praised for it).

I wasn’t exactly suffering from an imposter syndrome. I’ve mostly worked as a lone wolf before that (although I did have a mentor), and I guess I did not have a point of reference. After working on various teams, I’ve learned that what I had accomplished was quite something, and, at the same time, I was quite surprised at how slow developers can be. A colleague recently pointed me to a quote from Steve Jobs where he talks about A players. In that quote he says:

I observed something fairly early on at Apple […] the difference between the average software developer and the best is 50:1; Maybe even 100:1.

If I’d read this ten years ago, I might not have believed it. Today, I can easily see that being true. I don’t consider myself the best by any means. I’m probably some place between the average and the best. I’m here to share an anecdote that shows the 100:1 differential is a thing, and what I think it means for developers.

What does 100:1 differential look like

I took a project on a couple of years ago. Since I did not have the time to deal with it myself, I took someone on to work on it. This guy was not some random novice. He worked as a developer for 10 years and isn’t a newbie by any stretch of the imagination.

About a year and a half into the project, the guy finally tossed the towel in. Having no other choice, I had to take over. The code base was quite complicated and did not work that well, plus his architectural choices made further enhancements quite difficult. I decide to rewrite the app. The rewrite took me about 5 days to get to the same point from scratch, plus a few more days to add missing features that were promised long ago, fix outstanding bugs, etc.

So let’s say the previous developer worked on it exactly a year and a half (although in reality it was a bit longer). That’s roughly 547 days. This gives us a 109:1 ratio.

That’s what a 100:1 differential looks like in real life. Even if we were to generously make excuses for the other guy, I don’t think it would go below 80:1 by any stretch of the imagination. I guess you’ll have to take my word for it because you don’t know the guy and I do.

Incidentally, this is simply comparing the execution speed. There are other things like quality, absence of bugs, extensibility, performance, etc. I can’t really measure those quantitatively, but what I can say is I believe these things readily factor into the speed metric, because poorly executed project will suffer further time loss over the course of time.

Remember that I’m not even among the best out there. I’m sure there are programmers that could probably pull off the rewrite in less than a few days. While 100:1 may seem impressive, I think the absolute best would probably go even higher than that. 200:1? Sure, I can totally see that.

What might be the problem

While I cannot be a 100% sure what contributes to this huge differential, I have some ideas.

First and foremost, inexperience plays a big part. This is sort of obvious. If someone doesn’t know much, they can’t be fast. Inexperience is also the most trivial of the issues as it is easily resolved by… well, gaining experience.

The second most common issue is fear of failure. There are probably other factors that might comfortably take the second place — including things like personal situation, fatigue, injury, illness, simply lacking the aptitude for the job — but I find that fear of failure is probably the strongest factor among the people I’ve seen in action.

Fear of failure is like a muscle cramp. It paralyzes the person and stops their forward motion. It causes the developer to constantly pause and consider all kinds of nasty scenarios that may prevent their software from working optimally or accepted by the peers, managers, employers, and other stakeholders. They also tend to look for excuses when the software they’ve written does work poorly (“It’s because of the library!”, “It’s because the previous guy wrote it poorly!”, “It’s because the specs weren’t clear!”, “You didn’t tell me that was necessary.”, “Your English sucks.”). When I hear these excuses I hear a fearful scream — “I did not fail! I refuse to accept it!”

This fear causes developers to make all kinds of crazy judgement errors. They skip steps when learning, they parrot popular beliefs without verifying them, they invent arbitrary rules that prevents them for going for a simpler solution, become defensive when confronted.

They usually compensate for the lack of knowledge by using the first popular off-the-shelf solution without any regard for the short- and long-term cost of their choice, or deep understanding of what the chosen solution does for them under the hood. After all, it’s all about getting shit done to make the potential of failure go away, and when fear is involved, cost does not matter.

When they get stuck, they procrastinate. They stop trying because “I would’ve done it brilliantly if I’d tried, but I didn’t try, so you’ll never know.” On the other hand, they may overwork so they can say “If I couldn’t solve this with so much work, it must have been really difficult problem! What more do could you possibly ask of me?” They may even get physically ill due to unbearable stress. And any combination of the above.

Of course, the degree to which one does all of this depends on how much they are afraid of failure, and whether they have developed mechanisms to deal with it constructively. I think, regardless of their performance, most (all?) developers suffer from these fears. The difference is, I think, the fast ones don’t see programming itself as the source of the fear. Virtually all fast programmers I know personally picked up programming as a hobby in a no-pressure situation. Or maybe they started at a low-pressure work or university setting. They had an opportunity to learn that making mistakes in programming is not that painful.

It’s not about the money

And then we have to point out the obvious non-factor: financial reward. People who are able to complete things 100 times faster do not receive 100 times more money for the work they do. The differential in terms of compensation is 2~3:1 at best. So increasing the pay does not contribute to an increase in performance.

I know companies love their reward schemes and performance charts. To be honest, I don’t know a single productive developer that loves these, nor any that are driven by these. In fact, some psychologists even claim rewards are generally harmful. I can see how that can be true.

What can you do about it

If you’re looking to become a high-diff programmer at some point in your career, here are some things that you might find helpful. These are things that work for me, and since I’m not you, they may not necessarily work for you. But whatever, It’s not like you’re paying for them. :)

Take regular breaks. You’re not going to get too far if you’re constantly overworked and tired. Your brain needs some downtime to sort and catalog the things you’ve learned, too. Finally, if you continuously punish yourself in each successful run, you’ll get demotivated and burn out eventually. Your brain will learn that no matter how many great things you achieve, you’ll always be in pain, and tell you to switch off and give up (that’s what burn-out is).

Program as a hobby. Hobbies are great because they don’t create obligations, and are therefore free of potential penalties. Unless you invent some crazy policemen in your head that are going to punish you every time you make a mistake, you will reap the full untainted reward of successfully completing a programming challenge, no strings attached.

Dive into problems head-first. Mistakes happen all the time. It happens to everyone. In fact, I’ve learned a lot more from making mistakes than from doing things right. I also learn a lot from breaking things. Breaking computers, breaking software, breaking… rules. You might have been raised to prefer not breaking anything, but forget that — you’re an adult now, and adults are, for the most part, hypocrites that do things kids are not allowed to.

Code, code, code, and code. Code the heck out of it. And then code some more. Nothing beats having written thousands upon thousands of lines of code. Of course, don’t just write the same things over and over again. Try different ideas. Experiment. Mess about. One unexpected thing you stand to gain from this is mental flexibility. You are able to quickly discard ideas that don’t work and start over without feeling discouraged.

Go read articles or books, try the ideas you read about, find out if they really work. In my earliest days, I had a rule that when I’m reading a programming book, I never just copy the examples. I try to anticipate what could come next and try to code it in advance. Or I just wander off trying different things. Then I use the book as verification. This immediately gave me two data points: my solution vs their solution. It also gave me an opportunity to see what else is possible with what I’ve just learned.

“Read the fucking manual,” as they say (or RTFM for short). There’s no need to sugar-coat that one, in my opinion. If you’re offended by one of the most helpful pieces of advice in the history of programming, you shouldn’t expect to become a high-diff programmer. There’s a huge difference between tutorials and manuals. Tutorials teach you step by step how you do things. Manuals teach you how things work, but leave it up to you to discover how to do things. Discovering these things on your own is an amazing experience.

Believe 100% in what you do. I don’t think you can give it your best shot if you don’t believe in it. And be prepared to be a 100% wrong, too. There is nothing wrong with being wrong. I’m constantly wrong. I sometimes change my opinion on how something should be done mid-project and it makes me cry. And you know what? It’s not the end of the world. I still progress in my career, I still learn a bunch of new things, and I become more productive. Maybe I’m wrong about this as well. But I don’t care. I believe it a 100%… for now.

Learn to think fast. Not type fast, but think fast. Think quick, implement quick, increase the percentage of things that work on the first try. I like to play with ideas in my head before I code. The more ideas I can put in circulation and process, the faster I will discover which ones I should try first — which ones are more likely to succeed. I consider taking a meditative walk along the river work, because thinking is a big part of coding. I also find that intuition helps a great deal. I’m not a psychologist or anything, but I imagine that intuition is fed by your deliberate thought process, even if the though process does not yield immediate results. You think about things, collect information, and then, when you “switch off” your brain starts working out the details. This then feeds into your intuition. Later on, you have that “aha!” moment.

Write better versions of things. I love this exercise. Find some library you love, and write a better version which fixes everything you don’t like about it. Read their source code, too, and try to understand why they do things the way they do it. Some libraries are written by true masters, and there’s a lot to be learned.

But do you need to be the A player?

Being an A player is not for everyone. This article is not there to convince you that everyone should strive to become one. I’m merely pointing out that it’s a thing and not just a myth or a misinterpretation of Jobs’ statement.

Being a B or a C player is perfectly lucrative today. The salary differential is not proportional to the output differential. In a way, B and C players are probably the smart people in that sense. They are able to make a lot more money per unit output.

However, I can say this for sure. Just like lifting something heavy is far less frustrating if you are strong, programming is far less frustrating if you are really good at it.