Yeah, this is something I had to learn when I was younger in my career.
One of the highest value devs I've worked with was nicknamed the "gold plated bulldozer." He's not a 10x dev. He's not a rockstar. But you know what he does do? He shows up every day and burns his way down the issue list. He doesn't complain. He doesn't try to only work on the exciting tickets. He doesn't cause drama arguing over this or that grand conceptual scheme or architecture. He just plugs away and gets things done. Sure, with a tough algorithmic or architectural problem he'd need to ask someone, but he'd just do that without any ego involved.
It didn't really click for me until I was looking at some long term stats for that team and realized in terms of pushing the ball forward, he was doing more than just about any of us.
I think it's disappointing people like that are not just overlooked, but almost held in contempt by the more startup end of the software industry.
I’m currently working at a company with lots of smart people.
But everyone wants to work on the sexy stuff. The core parts of the business either don’t get done or they are half-assed. It’s like a dozen monkeys banging at a dozen typewriters. Lots of noise but little productive work.
As the saying goes “everyone wants to come to the party but no one wants to clean up”.
Quality employees know not everything is fun or exciting to work on. Hell, some of the most important stuff is viewed as “boring”.
But valuable employees recognize what’s important for the business not just their own careers or own interests.
> But valuable employees recognize what’s important for the business not just their own careers or own interests.
That's valuable to the business. The problem is how to make it valuable to the employee.
When I started out in programming, I fell in with a set of people who attached a lot of importance to Delivering Business Value. It was what you did to earn respect within that group. Great for employers, but looking back, it seems a bit one-sided.
The usual answer is stock. But in any organisation larger than about five people, the relationship between your output and the stock value is too wobbly for that to work.
There's an arsenal of incentives like bonuses and promotions. But in practice, as many commentators have observed, those don't go to the people actually doing valuable work.
I think there are two different kinds of 10x developer. Really they're probably better called 3x and infiniteX:
3x: I once knew a developer who could write code about as fast as they could type. It would generally work, be inefficient, and sometimes buggy, but it moved the ball forward relentlessly. If you had a basic task to get done, this person could do it and be done in 1/3rd, or even 1/5th, the time it might take someone else.
infiniteX: I also once knew a developer who could solve problems almost no one else could. If you needed something to scale perfectly to accomplish a large task in reasonable time, this person was the perfect candidate. They weren't fast, and spent a lot of time just thinking.
It sounds like the guy referenced above was the 3x type.
in the original experiment (sackman, erickson, and grant) they were able to successfully solve programming-contest-style problems in a tenth of the time that other people required. so maybe ten hours instead of 100 hours. this should not surprise anyone who's worked on a programming team or who has looked at code they wrote ten or twenty years previously. the actual ratios were from 5:1 to 28:1, but that was an understatement, because some of the programmers couldn't solve the problem at all in the allotted time, if I understand correctly in some cases because they decided to solve it in assembly language. sackman, erickson, and grant suggested firing the 1× performers:
> Validated techniques to detect and weed out these poor performers could result in vast savings in time, effort, and cost.
complaints and issue lists were not evaluated, but rewriting twice a month would have resulted in not completing the tasks they were being evaluated on
Developing truly innovative solutions to hard problems? Doing the hard stuff like documenting code and writing automated tests? Fixing bugs that no one else could? Proactively identifying and resolving software reliability and performance issues?
Consistency was never a part of 10x developer definition as I understood it. That label is more often than not applied to "talent", however nebulous it is defined. Consistency is very underrated and hard to develop a habit for.
I call those types of people the Claude Makelele of programming, and for those not familiar with soccer I guess Dennis Rodman would be a close comparison.
Without the likes of Makelele and Rodman teams like early to mid-2000s Real Madrid and the 1990s Chicago Bulls would have had way less trophies and wins (the Real Madrid of that era was even nicknamed galacticos/galactics because of the amount of soccer stars they had among their ranks) .
One of the highest value devs I've worked with was nicknamed the "gold plated bulldozer." He's not a 10x dev. He's not a rockstar. But you know what he does do? He shows up every day and burns his way down the issue list. He doesn't complain. He doesn't try to only work on the exciting tickets. He doesn't cause drama arguing over this or that grand conceptual scheme or architecture. He just plugs away and gets things done. Sure, with a tough algorithmic or architectural problem he'd need to ask someone, but he'd just do that without any ego involved.
It didn't really click for me until I was looking at some long term stats for that team and realized in terms of pushing the ball forward, he was doing more than just about any of us.
I think it's disappointing people like that are not just overlooked, but almost held in contempt by the more startup end of the software industry.