But I have worked with a few people who were clear 10x engineers. Everything they worked on they did better and faster and cleaner. They could often solve problems that other skilled people couldn't even get started on. Yes, they usually picked important and impactful things to work on, but even when just assigned tasks from the grab bag of team tasks, they were still 10x faster.
Somehow these individuals were also 10x nicer too.
The only downside of working with them is going home and looking in the mirror and wondering why you can't match their pace. Oh well, I would trade the hit to my ego for getting to work in their codebase any day of the week.
Isn’t that just really obvious truism that someone who is hyper specialized and really good in one area say video codecs is probably not a 10x’er in frontend dev? Doesn’t make it fake, still a jackpot as far as employers and probably coworkers are concerned. Unless you’re someone like like Fabrice Bellard but he’s more like a 1000x’er so probably still be better than most at anything programming related
familiarity might be able to give you 1-2x edge but 10x+ comes from raw problem solving skill and research aptitude
I personally worked with (and managed) amazing engineers that are AT LEAST 10x more productive than the worst AND average engineers.
Assuming that they are toxic or hard to work with is something people say to feel "the same when all is taken into account". That's not the case, a lot of these great engineers are great people too making them objectively a lot better than the average engineer.
Another thing that sort of matches your experience is that they are 10x nicer. 10x engineers don't show off at all. They don't need to. What I've been finding is that engineers that think they're smart are probably smart, but they are NEVER 10xers.
Next summer they tried to get him back but he was already at a large search engine company down in the Bay. Of course, he wouldn't return. That's when they realized a whole class of engineers were completely invisible to them; they lucked out hiring him that summer but there was no chance they could attract someone like him full time.
1. Being a know-it-all
2. Unwilling to admit mistakes
3. Not collaborative
4. Not sharing knowledge
5. Unwilling to be coached
There are many more. These “not nice” traits are the same ones that will lead to stunting your growth as a software engineer.
This also needs a fair reminder, people suck at communicating.
One could imagine a society expending not insignificant proportion of GDP on R&D towards human cognitive enhancement. Same society could allow anyone to volunteer for the corresponding enhancement programs.
If one starts to ponder why we don't live in such a society, one is led to reconsider major incentives governing our public sphere and key institutions.
I don't think in the end there is a rational excuse for obvious lack of government-led or private-funded research into nootropics, neurophysiology of exceptionally bright individuals, and non-therapeutic gene therapy. The amount of research done so far is laughable, compared to obvious transformative impact in case of a breakthrough. As a "tech worker" and as a taxpayer I have to admit that the current nexus of large-scale sociopolitical trends is aggressively coercing me to spend my individual and very limited peak of energy, competence, intelligence and willpower towards advancing mostly deadbeat goals of the attention economy.
The small (in absolute terms) fundamental physical difference between the best and merely good enough should not be an insurmountable abyss we take it for.
I don't want to be a 2x engineer for your corporate monstrosity or yet another fast-growing CRUD app. I want to be a 2x engineer putting in meaningful work towards implementing the timeline where anyone, myself included, could become a 10x or a 100x engineer by undergoing affordable and safe gene therapy.
The basics for being productive are 1. be in good shape (sleep and exercise) 2. not having to do less important stuff (someone cooks for you) 3. not having any more important stuff to do (no side business, spouse and kids don't demand more of your time).
Similarly, the best way to get moderately wealthy isn't to make a lot of complicated investments, it's to marry someone else who works and buy a house together.
They may have actually closed tickets 10x faster (which I doubt), but that wasn't providing 10x the value to the company. If there was one person who was resolving 10x the issues of everyone else, that person would be a (very overworked) legend. And I doubt they could keep it up. But it isn't like the company they work for will make 10x the revenue or produce software that is ten times better than the previous version.
The person you're describing is good at their job. There's no need for a number. We don't describe fast food workers as "10x fry cooks", even if they are faster than everyone else in the kitchen.
I've worked with 10x engineers maybe 2-3 times in 20 years. One single-handedly wrote 85% of <extremely popular and complex app you've used> and another wrote most of the internal libraries at <company you've heard of>. They would regularly take tasks that most people would take a month+ to do, and just knock it out in a couple of days -- over and over.
There is a trap here, though. There is another group of engineers, who jump on any greenfield project before everyone else manages to discuss the plan and then they write some code very quickly, showing you a "finished" solution. Those people often appear 10x to management as well. However, after deploying their code to production, it turns out it has many issues and is a source of never ending frustration for the people who maintain it. Unfortunately at that time the "super hero" has moved to a new greenfield project, and is not willing to fix their bugs or help because they are "busy" or "in a flow".
I don't think those people are really 10x. They are often an annoyance to the rest of the team and if the management doesnt break this pattern early, you end up with a team where one person codes 90% of stuff, gets most of the credit, but 10 other people get frustrated maintaining it, and overall the team pace is not 10x higher, but may be even slower than a similarly sized group of average devs.
So if you are in a management position, don't just look at how much code a person writes in a short time or what percentage of the product they created, but also look at the quality of their work and how good they are at sharing their knowledge with the rest of the team.
Having said that, I have met some true 10xers who created high quality stuff fast and were very helpful to their teammates, but they are quite rare and often don't get all the praise they deserve, particularly in environments valuing the "ship fast and break things" strategy.
For most businesses, a greenfielder is a 10x engineer.
(This is just an aside, I agree that there exist “true” 10x-ers having had the joy of working with 2 of them over the last 20 years).
So the controversial nature comes from the implication that most of the workforce (1x engineers like myself) are worthless and not worth hiring, and also the hubris of thinking a 1x company can hire and retain a/only 10x engineers (these same startups/companies usually offer a 1x or less compensation package). If you think I'm wrong, then fire 90% of your engineers and see where that gets you; that would be an interesting result if productivity increased!
I think this is separate from mere jealousy or denial; 10x engineers definitely do exist and I look up to them for inspiration and example.
Completely agree. That's recruiting/marketing bullshit. They're trying to appeal to people's egos, but probably have the opposite effect, as you say.
Also, I doubt one could actually recognize these top-tier engineers, at least not in today's standard interviews. But... I did actually job-interview a 10x'er for a startup years ago. It wasn't a standard interview but rather a long, casual lunch (he was a friend-of-a-friend). After two hours of talking about engineering/coding/etc, I started to suspect: "Huh, I think this guy might be a better than me." What I didn't realize is just how much better than me he would turn out to be -- it was amazing and a joy to learn from him.
When you were in school, weren’t their students just far more capable than others? When you look at sports, aren’t there just players far more capable than everyone else (any pro player vs any non pro)? When you look at art, aren’t there just artists so much better than others (professional artists vs a hobbyist)? Salespersons? Dog trainers? Snowboarders? Etc
Every discipline has a bell curve of skill, and there are engineers who are just significantly better than others and it’s not even close (like any profession). There are limits, but software engineering isn’t anything special here where the idea of outliers warrants this much controversy.
Yes there are “10x engineers”, obviously, because every domain has skill levels spanning magnitudes. It seems like the only thing preventing recognition of this fact is ego (and to be clear, I don’t think I’m a 10x engineer at all)
That also means not having a petrified terror of failure.
Yes, there are 10x developers and this is measurable. It’s a progression of the Pareto Distribution. People scared shitless of originality, most people, cannot see this because their life goal is to crush it with internal processes.
There are literally two different aspects of intelligence: "lack of brain fog" and creativity. Both aspects of intelligence are different and being strong in one doesn't necessarily mean you're weaker in the other. Lacking brain fog does help with creativity, but creativity is still an independent pillar.
Creativity and originality is actually less evident so it's less recognized. 90% of the 10xers you see are just super sharp, and they likely only have average or slightly above average creativity. Someone who has high skill in originality is much harder to recognize and their solutions are so novel that many times the solutions are ridiculed, unrecognized and dismissed.
Two famous people who excelled in these different aspects of intelligence are Von Neumann and Einstien. To quote someone who knew them both:
"I have known a great many intelligent people in my life. I knew Planck, von Laue and Heisenberg. Paul Dirac was my brother in law; Leo Szilard and Edward Teller have been among my closest friends; and Albert Einstein was a good friend, too. But none of them had a mind as quick and acute as Jancsi [John] von Neumann. I have often remarked this in the presence of those men and no one ever disputed.
But Einstein's understanding was deeper even than von Neumann's. His mind was both more penetrating and more original than von Neumann's. And that is a very remarkable statement. Einstein took an extraordinary pleasure in invention. Two of his greatest inventions are the Special and General Theories of Relativity; and for all of Jancsi's brilliance, he never produced anything as original."
I love this description and it matches my experience. Most people will both lose time with false-start approaches that are scrapped, and then with a sometimes endless series of commits at the end to patch up problems. The top engineers I've worked with (1-2 a decade) somehow just manage to avoid all that lost time.
It's not measuring the same thing. A 10x engineer might be compared to a full tenured professor with a high citation count. Einstein and Neumann are luminaries of human thought.
The great engineers I know have done it all before. They've worked on similar problems. They're not really breaking new territory.
I think this is where being 'prolific' matters.
Beethoven was a genius, but it makes no difference that he was smart if he didn't spend years and years just 'writing' music, transposing, experimenting etc..
That's the advice big composers give today i.e. 'you have to move quickly'.
If you were to watch someone build something, relatively quickly, you might be just amazed. But there is a lot of practice and trade-craft / craftmanship going on.
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]
The 10× number was intended to be qualitative rather than quantitative. They openly acknowledge that there is no one single measure of productivity by which all engineers can be measured, but point out that productivity does vary quite a lot from person to person, and that you shouldn’t expect engineers to be fungible. If you have a 10× engineer, you should do your level best not to lose or misuse them; replacing them might involve hiring a lot of people. That includes not just paying them more, but also allowing them to choose what they work on. Salary is an extrinsic motivation, but choosing what to work on is an intrinsic motivation. Intrinsic motivations trump extrinsic every time.
They also take the time to point out that productivity cannot be the only way that you value the people in your engineering teams. For one thing, not everybody in an engineering organization is actually an engineer, and they matter just as much. Even the project and people managers matter a lot to the ultimate success of an engineering project.
They also point out that there are very frequently team members who are average or below average engineers, but who still manage to improve every team that they are a member of. They’re the ones with non–engineering skills that they use to bring the team together, get everyone to like each other, build esprit de corps, etc.
A lot of advice in the book will seem quaint by today’s standards. For example, there is a whole chapter about offices. It recommends putting no more than two or three people in a single office, and recommends that part of that space be used for communal furniture like couches, coffee tables, bookshelves, etc. Engineers should design those offices themselves, drawing on a pool of real estate and furniture owned by the company. The offices used by an engineering team should all be near each other, but not near the offices of their managers, lest the managers get the idea that they are supposed to be involved in the engineering in any way. Of course today most companies would rather cram hundreds of people into a crowded and noisy open–plan office. On the other hand, it is possible today to do good engineering work from home, and not need offices at all. That wasn’t possible at all in the 80’s when Peopleware was written, let alone the 60’s.
But the insights about building high–functioning teams by understanding the individual people that those teams are made of are timeless.
The notion of context is exceptionally important because it relates to Price's law ( https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price ). You see this in big tech like crazy where most engineers are trying to get a few things done in a massive code base, and then many decisions come from on-high via principal engineers. As a former senior principal engineer, I've been there, seen it, and enjoyed it.
The question that haunted me was how to help more people grow into higher roles, and the problem is a lack of scope. This lack of scope is oppressive as there are only so many creative needs and the volume of toil is hard to avoid.
So, yes, if you have the right context, then you can do great.
However, we also can't dismiss intelligence, memory, or experience as multipliers. The unfortunate fact is that these are not uniformly shared, so there are a bunch of people talking over each other.
Worst yet, we don't have a common way of thinking about experience, and here Price's Law reveals an ugly truth: deep experience is rare.
The important factor is not speed but output.
Some people can do things that almost everyone else would consider impossible.
Having even a single one of those in your company can be the most important factor of success.
Fabrice Bellard https://bellard.org/ and Justine Tunney https://justine.lol/ are good examples of this kind of people, but there are of course many others.
That's pretty much my general philosophy when it comes to writing software though. Whenever possible, figure out what tooling would have made the task easy and then build that and solve the problem simultaneously. You're probably gonna have to throw away the latter code, but at least the next time it'll be easier, because you now have the tooling. Even better if you happen to be in a position like mine where you already build tools for others, because that way other people will end up benefiting too.
Anyway, does it still occasionally get me in trouble? Yes. I not infrequently end up in situations where the software is essentially done, but I have to write a compiler pass to make it actually work, because I decided to write the code in a way that I thought it should be written, rather than a way that would be performant out of the box. But hey, at least I'm aware of it (https://twitter.com/KenoFischer/status/1529814861693259777) ;).
Want more money? Study for an interview and then return to your minimal effort process. Believing that you need to give more is the company winning. Treat yourself like a shrewd startup business.
Their skills are limited to the particular framework and tools they used at their bootcamp, and they have less ability to learn new tools and languages than the average designer or marketing person. Despite their poor skills, 1/10 engineers generally think that they are the best, smartest, and most productive programmers at whatever company is unfortunate/dumb enough to employ them. Mostly because they take so much time to do everything, and they think that time spent is equivalent to productivity. But their code is so brittle, it can only handle limited scenarios and tends to fall apart under load. The 1/10 engineers frequently get into arguments related to tech issues into which they have no knowledge or insight, because they assume that being able to code makes them omniscient gods (this afflictions also affects many 1x programmers as well).
1/10 engineers are the reason so many LA tech companies (my employer included) no longer hire bootcamp graduates.
Here is my case. In my previous (small) company we achieved a yearly revenue of ~1M eur. I was super proud that I directly contributed 10% of that revenue.
My current team in Big Tech generates millions of revenue per month. I could do a small improvement in a week and generate more than 100k in value.
Does that mean that I am 100x because my impact is 100x? is it even my achievement at all?
It's true that high performing engineers perform high leverage activities, but if we take it at face value then excellent engineers stuck in low value companies/products would be much worse than mediocre engineers working in high impact products.
Surely the answer is somewhere in between. Great engineers do the best with what they have available. Sometimes they might influence their environment to increase leverage but this isn't a given.
> but my work at Sendwave led to saving well over 10x more money, because the scale of the product was bigger and the improvements I was making were more important.
We (the original startup crew) finally figured out what the problem was: their commitment to ANYTHING (our HW project but also every other product they've ever worked on) is exactly the same as how most people treat school and homework, namely, how much can get away with NOT thinking and doing about it and still get a passing grade.
They can't be "fixed" because that's how deep the problem is: they've been trained for this attitude since they were children and they wouldn't know how to break out if their lives depended on it; they are not dumb or low-IQ. But they've been trained to achieve the lowest-common-denominator of anything they design or engineer.
This has never been how any of us have approached anything in life. For us, it's:
1. Do the best job regardless of what you could get away with
2. Focus on the big picture and little picture integration
3. Know who actually makes the product a success: the customer and the market
Significantly IMO I went to elite schools on merit rather than legacy/money while my co-founder was home-schooled and didn't actually finish his BS but he has more drive and commitment than 99 out of 100 BS EE or CS degree holders I've ever met or worked with.
Most people mouth the words but either don't actually know what they mean or do not mean what they are saying when they say them. This may not be sufficient but I think it's a necessary difference between normie engineers and 10x engineers.
- Yes, some engs write code faster than others. 10x seems really high, so therefore 10x engs don't exist.
- Yes, some engs are more productive / pick better problems to solve / force multiply their teammates, but 10x seems pretty high, so 10x engs don't exist.
If we hadn't anchored on 10, we wouldn't be disputing that some people are more productive or faster, so I find proving or disproving the 10x eng to be pretty tired.
Good article though on the context for why some people are faster or more productive.
Now, is that a good or a bad thing?
Once upon a time, I was tasked with creating a new social media api based off of existing work by our "rockstar engineer." This is a guy who spend every single free second reading Code Complete and Code and Programming Pearls and seemed to have injected Design Patterns directly into his veins.
The last time he created a new API based off of his existing work, it took him about 2 days. I had zero experience with it, so it took me a little over 3. He was a person who was very proud of his work and declared that there was no reason for me to take that long to implement the new code.
The code review process at the company has a lot to be desired, and he being the "rockstar," basically got his code handwaved through by our CTO, who was filling in as our last manager had taken another position. Deciding I had enough, I went to the new manager who had no inkling of this dev's reputation and asked him to code review the original commit to the base social API with me for real this time. I asked him to keep in mind that other devs were going to have to build their work based off of this base system. It was a convoluted, entirely over-engineered pile of crap. A wankfest masquerading as code.
See, I read and was familiar with all of the books that sat proudly displayed in his cubicle. But there's a time and a place for everything, and the only 10x about this guy was the amount of unnecessary code he produced in order to do something as simple as interfacing with Facebook.
There are definitely people of a certain caliber who can solve problems others cannot, or way faster, from soup to nuts.
But when it comes to a large preexisting code base, solving prohlems in code can be done in different valid ways, which reflects our thinking patterns. Each of these ways then has corollaries about how the next set of problems is better solved in it. When one developer who has been with the company longer, given more clout for some reason, lucked out to be the green fields guy, or maybe really was somewhat better than the others gets to have his thinking pattern become the first principles of the major feature set, he may seem like he's 10x, but I'm not so sure with a different set of initial conditions that it would be so. And I think a lot of the measurements are taken on code bases in this gray area: not solving code interview problems.
Then there's the question of speed to full execution vs. maintainability, quality of the solution to deal with the next set of business demands, etc... I'm just not so sure it's that easily measurable.
On a 6-month crash project with 1000 engineers assigned, at the end, fully half the code delivered was his. You can't get any more objective than that.
To be clear: this was a project where, if not delivered on the 6-month mark, the company would not be paid. It is hard to see how, without his work, the project could have delivered on time.
I have worked with a few others of similar ability. I have never had a bad experience with one.
> half the code delivered was his. You can't get any more objective than that.
Counting lines of code is a famously ineffective way to measure productivity. It encourages low-density code style, and encourages working on easy development tasks. It also encourages prioritising velocity over quality, although in many contexts that may be what you want.
In the event, he assigned two-week tasks, and where not done on time he would do them himself over the weekend. During the two weeks, he would do up to ten such tasks, despite that he reserved the harder tasks for himself.
If you take physicists with Ph.D. plus 3 years of post-doc as the baseline, of course top physicists are 10x the baseline. And don't interpret the 10x in a superficial silly way which makes post-docs stronger than Einstein.
This goes the same in sports, arts, academics, etc. As long as the field has enough depth for growth, the top players can easily be 10x compare to the majority.
Aggregate productivity metrics are...difficult. But if one assumes that salaries are roughly proportional to value produced, it's not uncommon to have >10:1 ratio in the top professional tier of a sport, much less the whole of a professional sport.
E.g., the NFL has about a 25:1 ratio https://www.comparably.com/salaries/salaries-for-nfl-footbal...
MLB has a 700k minimum salary, a 1.1M median salary, a 4.4M mean salary, and a top salaries of $43.3M (that's a more than a 6:1 mean to minimum, and almost a 10:1 maximum to mean ratio, and over 60:1 overall ratio.)
https://www.baseball-reference.com/bullpen/Minimum_salary
https://www.usatoday.com/story/sports/mlb/2021/04/16/ap-stud...
https://www.spotrac.com/mlb/rankings/average/
> Being 10 times faster or 10 times stronger is beyond human limits.
“Fast” and “strong” measured in ways in which this is true are contributors to value produced, but not the measure of value produced by a player. A wide receiver that is the same in all other ways but runs half as fast as the fastest in the league isn't contributing half as much value.
It took 5 years of various clusterf**s with Unicode, but now whenever I approach it, I have an intuition for the cost of string manipulation, UTF8 v 16, what's pragmatic, what is needed, what is 'overdoing it'.
It's like building a deck - after you build 100 of them 'all the little details' become instinct.
So if you can do that across all sorts of technologies ... then you just walk through stuff like butter.
Whenever I see someone whip through something, I'm not amazed so much by talent or genius, but how they 'know so much'.
It's like the academic who's read literally 1000 books and remembers a lot of it.
Whether they are 10x or not really depends.
Some architectural decisions make a 10x difference.
Some business related decisions also make a difference.
Sometimes it's not apparent until later, or never apparent.
And sometimes it doesn't matter that much.
Finally - I'll say that 'speed of execution' is not remotely the issue. If someone can saunter along at a reasonable pace but actually produce the 'correct thing' - that's worth it's weight in gold right there.
The 0.1x ones don't really understand the problem they are working on, nor can they write even a few lines of coherent code, often with only a minimalistic understanding of the language they are using. Spotting them is easy: Watching them use the editor of their choice to work on code feels like watching a toddler learning to walk.
Different organizations happen to hire different kind of people. For some organizations hiring skilled developers is a matter of luck. The skilled ones they manage to hire are outliers, easily perceived as 10x. Other organization manage to hire mostly skilled developers and PIP the rest. In that kind of environment 10x does not exist.
That's the perfect base for an argument. Depending on the individuals background it is very obvious that 10x exists / does not exist.
But once you get past the pointy-hairs, all this framing does is set up a falsely quantitative comparison between broad swathes of engineers whose work can not and should not be compared in this way. Is it really any surprise that a meme created for the bean counters is going to draw ire and vitriol from passionate, diligent and opinionated software professionals?
There is absolutely no point in the general debate about what "10x engineer" is (or whether it really exists). Yes, people have vastly different skills. Yes, there are things which some engineers can do which others could never do. Yes, there are Dunning-Kruger cases without the chops, humility or awareness to acknowledge this. Trying to quantify and strictly define those things though? Pointless.
sometime it feels like people have to show-off or be the shining knights how save the day and want to be padded on the back constantly for that.
Maybe I've just been incredibly lucky with the teams I've ended up on.
"Please use the original title, unless it is misleading or linkbait; don't editorialize."
the real problem though is that IQ and 'programming ability' aren't really well defined.
A sign of low IQ is requiring everything to be well defined and scientifically validated in order to move forward in analyzing a problem. Science is slow and has huge limitations. Formally defining complex concepts like "what is life" is also incredibly tedious and so complex that it's often nearly impossible. Do you want to formally define "programming ability" before ever making a statement that intelligence is highly correlated with intelligence? Are we really stuck in some limbo of being unable to come to a fuzzy conclusion on such a simple concept because we can't formally define something?
Look at the world around you. What does your gut tell you? Do you really need a scientific study to tell you that walking into a wall is unhealthy? Do you really need a scientific study to tell you intelligence correlates with programming ability? The former is obvious, the latter is also obvious... but not to stupid people.
You're absolutely not stupid, but sometimes people end up limiting themselves by trying too hard to be more intelligent.
The difference with these people is incredible lack of brain fog. Everything is utterly clear for them. If you're a 10xer then this post characterizes the difference between you and others. It's not that other people are stupider, but there's a sort of brain fog that prevents people from seeing a solution. We sort of have to wander through a fog and look things up to arrive at a solution.
What you will find is that this brain fog is independent of creativity. There are many 10xers who aren't that creative.
I'll preface this by saying I've been described as a 10x-er by others my whole career. I do not consider myself one but I've noticed that what people respond to is my ability to break down problem spaces into very small pieces and think about it in the abstract.
I also notice that this is what I see in folks that I consider are 10x-ers.
It's also not that I think others can't do that. That would be hubris. However I think it takes practice, and practice first requires self reflection.
I'm currently mentoring interns and juniors, and I am trying to teach them to approach problems with that kind of thinking. The ones who can shift into breaking things down like that, are able to chew through stuff much faster and cleaner.
coincidentally the system architects I've worked with who can think like this are always the strongest at creating scalable solutions and adapting to change.
The thing that they miss is the novel solution. The WTF solution that's so left field it changes fundamental understanding of everything. It is even rarer to find these types of people. I believe the "creativity" skill is highly independent of "lack of brain fog" so often times the creative people aren't noticeably more intelligent because they have brain fog and aren't as sharp as the classically intelligent person.
They say that Einstein once called his secretary to ask about his address because forgot where he lived.
Worked with one and couldnt help him
the key difference I've noticed is that the slower the companies move the more obsessed they become with their tools adding piles upon piles of ceremony and requirements I guess jira helps folks do that but that's the case for almost any tool tbh
Let's stop with this juvenile dick measuring contest. We are not machines that have a speed that can be so easily measured like a new CPU in the bosses computer.
There's nothing juvenile about the observation that some people (and very few) are gifted with an order-of-magnitude stronger programming skills.
But, the thing that makes "10x" engineers is rarely their own work, its mostly luck of being in the right place at the right time. The big problem is that most people cannot reliably differentiate a "10x" engineer from a gobshite.
The reason why the "myth" is so tedious is that people mistake volume(of code/self aggrandising/speaking in meetings) for being _good_. Just because someone ported code from one language to another, doesn't mean it was useful to the business, or humanity.
