That is to say, some at this type surely can be managed, but it may take a really good manager (and even that may not be enough), along with team mates who are not only good, but also able to deal with such a team member.
Which in the end may negate the 10x productivity, or at the very least reduce it.
I guess one alternative is having them in their own “team” basically reporting to a director but having no immediate team members
I’ve been the 10x programmer several times in my career. Interesting positions that kept me hyper focused. Built out entire product lines, saved or made companies millions.
I’ve been 1x or much lower on uninteresting projects, or ones where I couldn’t get management to deal with blockers.
Some of these have been at same company. Just depended on the project.
In that case they are not 10x. They are not producing 10x value if they are making it harder on their coworkers.
> The one who really is 10x, knows it, everyone that worked with knows it, but they are just obnoxious about it
In that case they are still not 10x because if they aren’t reined in, no one wants to work with them and work still gets done slower - again not producing 10x value.
The core issue is the disconnect between leadership and other engineers: the leadership heaps praise on this person, gives them interesting work, and takes projects they think are “behind” away from others for their superstar to work on. The other engineers are left feeling resentful that they have to fix/maintain/extend/support this horrible tangled mess of code, while the “10xer” moves on and never has to deal with cleaning up their own mess. Sometimes management will actively protect the person’s time by asking others not to bother them with questions about their code while they focus on whatever’s next!
The features shipped have visible business value and are easily measured, but the impact on employee morale/retention/velocity is harder to measure, so it’s overlooked.
Yes. I've encountered more of these than I have 10x developers. In fact, I've FIRED more of these than I've encountered 10x developers.
That doesn't mean 10x developers don't exist.
There are plenty of smart pricks in our industry.
Also if you produce code and don’t bother leveling up your coworkers, you’re a long term liability to your company.
It's like insisting that surgeons are terrible people and pointing to Jeffrey Dahlmer because he also cut up people.
Whole idea is taken out of context. There is nothing about "superhuman 10x dev" it was simple realization that IN ONE TEAM there are developers who are 10x faster to deliver tasks and there are slower devs.
Just like in university group assignment there are slackers and there is that one person who does the assignment.
Worst of all is that people start assigning "10x" to themselves or others or judge others as "0.1x" - which is meaningless out of very specific context.
More so it means that there ideas, abstractions and frameworks result in substantially higher productivity for anyone working on the project than the average dev.
Beyond just the talent to do this successfully, you also have to give people the space and freedom to actually do 10x work... This tends to extend well beyond the narrow scoped requirements written in the current sprint of tickets.
When talking about 10x devs (or 10x any type of employee), it is about Judgement. The decisions they make on what they work on, how they achieve it, and (probably most importantly) what they choose NOT to work on. Judgement is the deciding factor in whether someone has a 10x impact on the business over time. It absolutely is not how much code they write. As a matter of fact, removing code can be a 10x improvement as well.
Programming, at least complex programming, is a gestalt of many skills ALL of which are probably a normal distribution (intelligence, focus, problem solving, political savvy, curiosity, experience, etc. etc.) How could it NOT have at least a 0.1x to 10x distribution?
Also, I do think there are 10x programmers that are 10x in a myriad of contexts, not just one team.
I am not botching your idea, I just have a different perspective of what the term “10x” means.
*Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring perfor- mances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. The converse may be true, too. The data showed no correlation whatsoever between experience and per- formance. (I doubt if that is universally true.)*
Now, is that really the 10x:ers fault?
People I have met in the the third type (true 10x-ers who know it) seem to have a lot more humility, in my experience, than suggested here. If you look solely at metrics like kLOC/year, they are often in the middle or bottom of the pack. They are not usually generalists, instead specializing in some area that is of high value.
When a single individual outperforms a large group the large group typically doesn’t like it, or the person doing it. Sadly that’s just a part of human nature. Where I live (Sweden) it’s referred to as the law of Jante. In other parts of the world it’s referred to as tall poppy syndrome or crab mentality.
I have a friend like this. I have never worked with them, but get to hear about how all their teammates are nearly useless on every team they work on throughout their career (mix of FAANGs and startups). Every time they join a company, they quickly become the team expert and biggest contributor, because they enjoy working long hours, spending their weekends coding, and are a very talented programmer.
I recognize they are extremely passionate for what they do, but I would never want to work with them personally. That kind of work relationship cannot be fun for anyone, except maybe the stake holders that are seeing rapid progress.
The one who is 10x at the expense of their colleagues [...]
The one who is, at most, 1.5x or 2x but think they are (and
sell themselves to the leadership as) 10x [...]
The root issue, of course, is that management essentially never has the time or chops to discern the quality (maintainability, readability, performance, correctness, etc) of the engineering work being delivered.
Management only understands timely delivery.
Even when management are software engineers themselves, they typically just don't have the time to be elbow-deep in the code their reports are delivering. This is particularly true in fast moving fields like front-end development where you have lunatics running the asylum and standards and practices change every three weeks. And even if your manager does get it, their manager probably doesn't, their manager's manager doesn't, the stockholders don't, etc.
I don't know the answer to this. It seems to me almost impossible to avoid this in a commercial setting unless you have a tiny team (less than 10 engineers?) and the CEO/CTO is a top-notch engineer.
Talk me down off of this ledge. Tell me it's possible.
as they should, because it's the only thing that matters to 99% of humans for any non-critical stuff (and honestly, even critical... even stuff that can kill humans, we are very good at saying "one chance of death in XXX is an acceptable risk" ; I'd wager that anything that is below the average death rate of car driving in a particular time / area is in general ok).
I'd rather learn a software that has bugs today than a perfect software in a year - by that time I've already organized my workflow around the bugs and already spent 1/30th of the time of my projected remaining future career around this software. I'm not going to re-learn yours even if it works better.
as they should, because [timely delivery] is the
only thing that matters to 99% of humans for any
non-critical stuff
The tech debt you accrue today in the name of "shipping fast" hurts your ability to execute timely delivery in the future.
That's why management should care.
I definitely agree you about the near irrelevance of tech debt in short lived projects.
the large majority is short-term projects which
But it really depends on if you're working at e.g. an agency vs. working on long lived in house projects.
Hate to break it to everyone but its really not like this, unless you're stuck in a loop of a bunch of resume driven engineers there's alot of stability in frontend development, especially since the advent of meta frameworks (Next.js, Nuxt, Modern Angular etc) and stability in tooling (rollup v2+, webpack 5+, and especially esbuild / vite)
If you want to be even more stable here, you can forgo a lot of headache with web components, which will always have some backward compatibility built in thanks to it being build on standards.
It isn't 2016 anymore. New frameworks aren't just popping up left right and center and expecting adoption. There's a lot of stability out there and there will be for the foreseeable future.
Much like any engineering endeavor there are, yes, people pushing the frontier, but all communities have this.
unless you're stuck in a loop of a bunch of resume driven engineers
- The one who is, at most, <INSERT ANY RATIO, EVEN NEGATIVE> but think they are 10x and get a very disproportional part of the money, promotions, praise, notoriety.
- The humble one, who helps mentor their colleagues to be better at what they do. They do this by helping provide critical insight at important junctures. By not attempting to grab the spotlight, but instead shine praise upon their colleagues.
These are people who help everyone get better. They are out there. While the first 3 are the loudest and most annoying, this 4th type is rarely self-identifying, often self-deprecating as they don't crave attention.
I've seen 10x that were excellent mentors. Perhaps not in a traditional sense, but through code reviews and answering questions. Everyone working with him seemed to improve really quickly.
I think the reason so many people have doubts on the existence of 10x is that they might have never encountered one.
I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.
There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" [0][1] (Some use the term "dark matter devs" but I know it has another meaning [2]). These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally). When hiring is red hot, they might completely disappear from the hiring pool by junior year.
[0] https://blog.pragmaticengineer.com/software-engineering-sala...
[1] http://danluu.com/bimodal-compensation/
[2] https://www.hanselman.com/blog/dark-matter-developers-the-un...
- The one who is 10x at the expense of their colleagues (they run fast and break things and leave to others clean what is broken, which is part of the reason that they are fast).
- The one who is, at most, 1.5x or 2x but think they are (and sell themselves to the leadership as) 10x and get a very disproportional part of the money, promotions, praise, notoriety.
- The one who really is 10x, knows it, everyone that worked with knows it, but they are just obnoxious about it. They consider themselves not just a better programmer but a superior human being. This one at least is productive and can be dealt with good management.
So when you have met those types, especially the first two types, it is natural to have sympathy to the idea that 10x is a myth. But, for me, it’s clear that they exist and some of them are nice people and great to work with, they are 10x in velocity and code quality, so they make your life easier as a programmer next to them.