10x developers do exist - but not in the way you think

10x developers do exist - but not in the way you think

I was reading on my holidays an article by Joe Reis (https://joereis.substack.com/p/how-good-do-you-need-to-be-at-your) in which he opines about airline pilots, developers and what it means to be good at your job. Good little thought piece.

I've been watching my brilliant eldest son (George, pictured above) who excels at stopping the ball from getting into the net, and the combined with Joe's article and the long thought about 10x developer pieces has meant it's now time for me to proffer up my bit of sagely advice on this topic.

Most people outside software development (and delivery) have this naive view that all developers are doing is "some typing" and that therfore the 10x developer has something to do with "the typing bit". This is why we get all this weird shit happening with lauding developers (and teams) that "do lots of coding" or "complete lots of stories". And yet, most of us who've worked for a while know that many of those who behave this way aren't just "a bit shit", they're generally "monumentally shit".

Why? Well, it's mostly because of 2 factors.

  1. Development is mostly thinking, not typing. Once you get to the typing part, that's like the "hammering in the nails". Sure, there's some skill in making sure they're straight, they're the right length to go through the board, but mostly it's a mechanical task. I'm sure I'll eventually write something about how important this part of the development actually is, but it's not where there's the "10x differentiation". Most of the improvement you get in here is "not being dumb" rather than "being really good". Sadly, there's far too many programmers that really have never been taught how to "not be dumb", and our industry is where we're at.
  2. Creation of software is about 20% of the total cost of that software. So, if you're looking at that 20% rather than the 80% (or even better the 100%) you're gonna get really bad outcomes. And, this is where the industry is at.

So, we're optimising and rewarding these developers who churn out mountains of shit, unmaintainable code and lauding them as the "10x developers". Now, if we start thinking a little bit more broadly, and leaning into our sporting tangent, in the past 6-8 years I've learned a lot about hockey. We weren't a hockey family, and just an accident of fate meant that George ended up being a hockey player.

There's a certain level of pressure that's on the "last line of defense" before the ball gets into the goal, but - and here's where it becomes really clear. The role of the goalkeeper is NOT just to use their stick, pads and reflexes to stop the ball. George can play at his best, and still have a 9-0 loss. He can play terribly and be part of a 5-0 win. Naive observers of the game will attribute the scoreline as the base of understanding the "worth" of the goalkeeper. George does have a pretty fair set of hands and reflexes in stopping a ball (again, check out the photo) but where he excels is his ability to understand the game, and use his brain to work out what the attackers are doing, his voice to let the defenders know how to impede the flow of the ball and most importantly the TRUST of the defense to listen to him when it all starts to get a bit spicy. (For more great thoughts on this, check out Andrew Charter https://www.garudax.id/pulse/goalkeeping-brutal-masterclass-understanding-your-realm-charter-kudpc )

How on earth does this relate to the 10x developer premise?

Well, hear me out. Firstly, we have to give up the naive interpretation of looking at the "score line" to determine how good a developer is, and when evaluating you need to be examining the results for

How many failure situations did the team get into, that could have been avoided?

Like a goalkeeper, the 10x developer is one that organises the play so the ball never even gets into the circle. The risks of goals occuring is managed by "good design", and by having the team all working coherently together to be constantly vigilant for those risks.

Look around your delivery teams, but don't look for those developers that are constantly "smashing out cards". Look for the developers that always get their work done, but it's done the first time, and changes to that work is easy, and simple and that other developers constantly say how "clear" the code is to work with.

Look for the developers leading their teams to make the 80% decisions, to make the code easy to change, easy to understand and teaching them how to do this. Look for the developers that are constantly aware of the decisions they are making and how the codebase (field of play) is affected. Look for the developers influencing their teams to work in a way that failure just never happens, rather than being constantly on the back foot defending against the failures.

They are your 10x developers, and now you know, go and nurture and reward them.



Thanks for the mention Jon. I love and agree with the analogy

To view or add a comment, sign in

More articles by Jon Eaves

  • Which champions will you choose?

    My dad used to tell me "A champion team will beat a team of champions any day". Now, he'd know a thing or two about…

  • Successful teams are bound by themes

    One thing I notice a lot about software delivery teams in this "post-understanding of agile" world is the rather weird…

    17 Comments
  • Microhabits - my core of software development

    I was asked a while ago by one of the very, very talented juniors that I mentor: "Why does all your programming look so…

    2 Comments
  • Don't be a millionaire's wallet protector

    I've been following and reading John Cutler for quite a while, and while they mostly post about product stuff…

    8 Comments

Others also viewed

Explore content categories