No one would take the time to learn from my way-too-clever code. They’d throw it away for more obvious code in a heartbeat. Because I’m not famous, I don’t work with other geniuses, and of course I’m not a genius so my way-too-clever code would just be annoying and uncharacteristic.
I think the difference here is that Carmack was working in a space where fast inverse square root was the difference between the program working and it not working. At that point, it doesn't really how matter "clever" in any bad sense of the term the code is.
Carmack works in 3D engines, which even today is a space where people are trying to wring every last cycle out of them. It's perfectly appropriate when programming in a space where every last cycle counts to program as if you're in a space where every last cycle counts.
I don't work in such a space, so I don't program that way. But while I haven't got anything as "clever" as FISR, I have got some things like non-obvious database schemas for certain performance reasons that if my successors don't find and read the comments I've left about why the schemas are that way, they could well get themselves into some trouble if they try to "fix" it.
Pentium 3 released in January 1999. That CPU, along with all newer ones, support SSE which has RSQRTPS instruction, faster, also much more precise approximation.
AMD had it before, PFRSQIT1 / PFRCPIT2 in 3DNow from 1998.
Quake 3 Arena released in December 1999. The point of using that approximation is running on older hardware, like Pentium and Pentium 2.
FISR is a beautiful hack, but it hardly technical debt. This is the original code. Note how the trick has been hidden behind a normal API such as `Q_rsqrt`:
float Q_rsqrt( float number ) {
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
return y;
}
If the comment "what the fuck" were instead "estimate floating-point exponent with bit-wise arithmetic" and "SingleStep forward with Newton's Method", then the code would be better documented
The comment "what the fuck" and "evil floating point bit level hacking" don't help anybody. And "1st iteration" is only helpful if you knew it was an iteration of Newton's method.
What I would call technical debt is if he had inlined those tricks all over his code, making it very hard to debug a wrong result or move away from this technique.
Carmack didn't come up with that: https://en.wikipedia.org/wiki/Fast_inverse_square_root#Histo...
I think Elon Musk is another good example of this phenomenon.
Certainly, there are programmers vastly more productive than the average, but I think when you think of any legendary programmer (Linus, Carmack, Knuth), you're also likely impressed by their significant supporting cast.
Its been over 40 years and he's still writing "Art of Computer Programming" books, and fixing errors in the text. Its an exceptionally well-crafted piece of writing. His solutions to various programming problems are excellent too, great analysis and deep thought applied to them.
Definitely not the "10x programmer" of today's lore. Knuth is an older, gentler kind of genius that I have a huge amount of respect for.
---------
For those who haven't read Knuth's works yet, I suggest starting with Knuth's analysis into Alpha Beta pruning: https://pdfs.semanticscholar.org/dce2/6118156e5bc287bca2465a...
Knuth's writing style is just so much deeper and thorough than pretty much everything else. You have to give the guy mad respect.
Of course, I also recommend reading "The Art of Computer Programming", but that's far more material to read through. The ~34 pages on Alpha-Beta pruning are a quicker introduction to Knuth's writing style. Even if you think you know how Alpha-Beta pruning works, Knuth goes far deeper into the subject than you might imagine.
EDIT: In particular, the F -> F1 -> F2 algorithm (F being Minimax, F2 being Alpha-Beta, and F1 being an in-between algorithm to help describe F2) is brilliant writing. Only Knuth would spend so much effort describing F1. But all that effort into F1 helps both his analysis, as well as better describes what is going on in Alpha-Beta pruning (aka F2).
An awful lot of game-development history was spent actively looking for 'clever' hacks that would verge on fireable offenses today. Pokemon Red was made barely-possible via the sorts of magic-number tricks most of us don't even like to think about, but at this point that sort hand-optimization is basically just code golf for its own sake.
I remember doing Javascript games in 2007 (before V8 introduced a JIT to JS) and very carefully optimizing loops, avoiding DOM calls, eschewing JQuery, etc. to get acceptable performance. As late as 2009 we were counting bytes on the Google search results page (like literally; we'd do things like "for(var i=0,e; e=c[i++];)" to save a byte in a foreach loop). Solidity programmers on the Ethereum VM today use tricks like switching out opcodes and moving functionality into library contracts, sometimes at the expense of locking tens of millions of dollars worth of ETH forever.
Nobody counts bytes or manually moves common subexpressions out of loops in JS today; you just use Babel. But as computing matures, the bottleneck moves, and people seek out new domains that are just becoming possible, and then have to develop a new bag of tricks.
As an example everybody uses an OS to code. An OS is incredibly complex. Maybe one of the most complex piece of software. But it doesn't mean that you should care about it. With the proper and clean interface it will have an abstraction of this complexity to its user (in your company or not) and they will be able to continue to code and never have to care about it.
So of course an OS - or like OP said anything creating value - doesn't mean that it creates technical debt only because it's complex.
Similarly, whatever you're building likely uses a microprocessor somewhere. You probably don't really understand how that works, and would not be able to build one from scratch. But without that CPU, you wouldn't be doing your job at all.
The phrase "standing on the shoulders of giants" comes to mind here.
If you want people to accept and learn from your clever programming techniques, try to find ways to turn them into products that only you can make that lots of people will pay money for. Even if you don't succeed in convincing the rest of the industry, at least you'll have lots of money.
Doom would have been revolutionary even if it and all of the other games it inspired were free.
Similar to idea that it's hard to write simple, clear code, but easy to understand it.
Carmack didnt write it, 0x5f3759df constant landed at iD from 3Dfx/Silicon Graphics
https://medium.com/hard-mode/the-legendary-fast-inverse-squa...
There are certainly lots of programmers who produce 10x more value than others, and some who produce 10x more than average. They create good project plans that don't need reworking midstream, build tooling pipelines that save work for their whole team, catch obscure-but-expensive bugs in advance, and make sound design/infrastructure choices which save huge amounts of renovation down the line. And yeah, for sufficiently-hard problems they sometimes come up with clever technical solutions other people wouldn't.
I suspect there are engineers who can frequently output quality code 10x faster than most of us would, but that's reserved for incredibly specific tasks. Most code-writing genuinely can't (or shouldn't) be accelerated like that, so it's limited to arcane problems like rendering or codec work where brilliant optimization can trump general diligence. John Carmack might be an example, or Dennis Richie, or Gary Tarolli (who apparently first authored Fast InvSqrt). The Microsoft gurus who hand-edited the EQNEDT32 binary for a bug-fix, too. But there are maybe a few thousand programmers in the world doing that sort of work, in a very specific set of fields.
Meanwhile there are a lot of companies trying to hire "10x engineers", often for "make our website and backend" tasks that can't possibly be solved with a brilliant coding trick. And a lot of those companies aren't looking for someone who will do the architecture and task-analysis and tool-building that makes 10x-value engineering possible, they're looking for someone who will solve simple problems inhumanly fast. In practice, that mostly means cutting corners, hard-coding values, and skipping on documentation.
That said, I'll bet this kind of 10x programming is genuinely rarer these days. Not because programmers have gotten worse, but because new tools and relaxing hardware constraints make this sort of near-metal optimization less necessary and less valuable. The sort of data-reuse hacks that made e.g. Pokemon Red/Blue possible would just be a pointless headache today, so those same skills are getting spent on code golf instead.
in which a VC once again proves that what passes for "wisdom" in Silicon Valley is often indistinguishable from what others would assume was satire.
It seems to go like this. A lot of programmers are weird. They don’t get along well with people. They keep weird hours. They dislike social norms. This part is true, although far from universal. The problem is the next step: since programmerness is associated with all this weird behavior, the most extreme and therefore best programmers will be the ones who behave the weirdest.
This is reinforced by a simple selective process: mediocre programmers who behave badly tend to get fired, while genius ones are often kept around because their abilities outweigh their flaws (or at least management thins they do). Thus, when you see a really weird programmer on the job, chances are that they’re also really good.
It’s all bullshit as far as I can tell. Plenty of great programmers have fine social skills, work 9-5, enjoy teaching new people, etc. Plenty of crappy programmers are also weirdos. But the perception is definitely there.
This discussion of 10x programmers and sometimes denial that they exist is really people pushing back against the notion that weird or bad behavior is a signal of greatness, or that productivity means you can treat people like shit.
Exactly. No one sensible disputes that, given the right circumstances, some engineers (or business leaders, etc.) can bring more value to an organization or culture broadly than ten or more people who are just OK.
But pretty much everyone I know who I consider exceptionally valuable is also good at working with others and enabling teams to be successful.
https://twitter.com/skirani/status/1150019060467240960?s=20
"I am surprised by extreme views on 10x engineers. They are great individual contributors. They may not be good with teamwork. So what? They can be phenomenal in the early stage of the product cycle.
Find the best in each & get the best out of them. That's what good managers do."
The overall picture is of someone who is technically competent but "moves fast and breaks things". The person who coined that phrase perfectly embodies the upsides and downsides of this type of person: Zuckerberg quickly threw together a PHP app, is a gigantic jerk, and he is a billionaire because his product was phenomenally successful. Then other, kinder, gentler and more team-oriented people came later to make the product performant and legible. If the team-oriented people had been involved from the beginning you would have gotten Google Plus.
It stands to reason that such a person would be more likely, on balance, to be abrasive and dislike meetings. I guess the only problem I see with his formulation is that a "10x" engineer is implied to be better than other engineers. Atwood's "you need all kinds" formulation is better.
That’s what all this pushback over “10x engineers” is about. It’s not pushback against the notion that some people are really good at what they do. It’s against the notion that those people are necessarily asshole loners.
It’s a common broken syllogism that goes like, Zuck built Facebook into an empire with his bare hands, Zuck is an asshole, therefore Zuck was successful because he’s an asshole, therefore if we want to succeed we need to hire an asshole.
Alternately: our guy is an asshole but that’s ok because that’s what you get with a 10x engineer. We need that 10x so we need an asshole and therefore if you want them to stop being an asshole then you want this company to fail.
Alternately: there’s no excuse for being a jerk and people are tired of it being justified on the basis that it’s a necessary component of being great.
In my experience there is little correlation between programmer productivity as an individual and things like kindness and ability to work in a team. Plenty of geniuses are friendly people who work great with others. If you hire one of those for your early stage startup, you’ll not only do fine, but you’ll be in a much better position once you reach a point where you need a team.
A distinction should be drawn between a "good programmer" and "person good at startups and greenfield projects". I would maintain that the latter requires a certain amount of assholery.
Really good products are not made by committee, at least not in the beginning stages. Committees and large groups of people also tend to slow things down, a lot. You have to be willing to be opinionated and self-assured to maintain a cohesive vision of where you want to go, and that necessarily means pissing people off. Steve Jobs, Linus Torvalds, and possibly Elon Musk are other examples.
So while 10xers in terms of pure programming skill will not be enriched in assholes, the famous ones will generally be, because they got in on the ground floor. The ground floor is where it helps to be an asshole. Most of us here are not dealing with such situations though, so I would agree to the extent that for 99% of employers in 99% of situations, considering assholery to be a positive trait is very unwise.
You mention Steve Jobs. What about Woz? Without Woz, Apple never would have gotten off the ground. I suspect most of us would agree that Woz is not only a 10x engineer, but probably a 100x. At least, he was in the early days of Apple, before the plane crash. And he’s a super nice fellow.
One thing being an asshole helps with is becoming famous. Everybody knows who Steve Jobs was. Approximately nobody outside the tech community knows about Woz. So naturally, if you go looking for examples, you’ll find lots of assholes. That doesn’t mean assholery correlates with (let alone causes) success.
If we flip this around, does anyone doubt the existence of 1/10x engineers? I’m not referring to low end outliers who clearly can’t code. But I f you think through all the engineers you have known who have actually been employed and worked in the field, is there a 10x spread between the best and the mediocre-at-best?
Lots of folks are familiar with the Dunning-Krueger effect for what it says about the perspective of those with less experience/skill. However, it also postulates that people with more experience/skill also see the world incorrectly — from the other direction. They are prone to assume that most people are at least as skilled as they are.
This pushback against the notion of a 10x engineer seems like the perfect union of Impostor Syndrome meets Dunning-Krueger. We worry that we’re near the bottom of the curve due to our own insecurities while being partly blinded to the deltas in skill both above us and below us.
Edit: Clarified that I was interpreting 10x as highest to low-average, not highest to lowest outlier.
Ten percent of Usain Bolt's top speed (27 mph) is a leisurely walking pace that almost any healthy adult can maintain for 100 meters. Ten percent of a world record marathon is a bit harder, but high school students still routinely under 10 minutes for 2 miles.
E.g. Usain bolt makes far more than 10x money from running than the average healthy adult.
Because identifying, hiring, and keeping 10x programmers is difficult and expensive. Companies fail at it and assume the problem is the concept of a 10x programmer, rather than own inability to handle this difficult objective.
There a lot of hiring managers, who think the process has one step: post a job 'looking for 10x engineer' and then judge the results. Rather than consider that their approach might be flawed, they attack the concept of a 10x engineer.
There absolutely are 10x people out there in many fields, and many of them are humble about their methods/approach. Software engineering might even have 100x people.
Forget 10x developers. Forget berating developers for checking in code that doesn’t compile.
If you are planning to build a real growing company, You need to progressively put more stress on your SYSTEM. That is your job.
Have a kickass onboarding set of tutorials and documentation for everyone. Have a culture that anyone can assign an issue to anyone, instead of interrupting them. They can get feedback via updates on issues.
Use pre-commit and post-commit hooks to catch as many mistakes as possible, and clean up team formatting standards for your code.
Hire developers who are super familiar with whatever technology (language, platform, techniques) that you need them to work on. But NO ONE SHOULD BE A HERO, everyone’s code should be easily understandable, use only the simplest language features to get the job done (but no simpler), and be documented. Accrue no code code debt.
Each developer’s work should be documented and tested, preferably by someone other than themselves.
Each developer should be replaceable. That extra 30% cost spent on fully documenting and testing their code means months saved onboarding someone to take over.
Working remotely is actually GOOD. Working asynchronously 90% of the time is even BETTER. Everything in your system should assume people don’t share time or space.
People live lives. Companies build products. That is our motto. It means exactly this... ask yourself whether you are building a product, and if so, do not give responsibility to PEOPLE, but to the system. If they take a day off to spend with their kids, or work 3 hours a day, it shouldn’t have a major effect on the product.
And our compensation model reflects this, too. Instead of full-time employees, feel free to take anything from this:
https://qbix.com/blog/2016/11/17/properly-valuing-contributi...
This attitude makes perfect sense from a managerial perspective. If workers are easily replaceable, they don't have negotiating leverage and you can pay them less, and you don't have to worry about risk to your company if one of them gets hit by a bus.
Conversely, it is in an employee's interest to be hard to replace if they can be. It gives job security and negotiating leverage. A "good" 10x engineer, the ideal stereotype, would be hard to replace because by definition, you'd have to hire 10 people to replace them, and even then, the 10 might not be able to accomplish certain hard tasks.
The bad stereotype of a 10x engineer is that they wrote a business-critical monstrosity only they can understand.
What they both have in common is that they are hard to replace. That is why, I think, that when big companies hire well-known 10x engineers, they put them on non-business-critical research type roles. And smaller companies would presumably be wise to avoid them altogether.
However the compensation model you describe seems a little wild. I'm not sure it's that easy to tie projects to specific performance numbers.
I googled him just now knowing nothing about him. Holy cow. How can this person even be real? Are we sure he's not a superintelligent alien?
>In 2005, he designed a system that could act as an Analog or DVB-T Digital TV transmitter by directly generating a VHF signal from a standard PC and VGA card.
WTF! How??
> On 31 December 2009 he claimed the world record for calculations of pi, having calculated it to nearly 2.7 trillion places in 90 days. Slashdot wrote: "While the improvement may seem small, it is an outstanding achievement because only a single desktop PC, costing less than US$3,000, was used—instead of a multi-million dollar supercomputer as in the previous records."
This guy is more like 1000x than 10x.
IMHO, he stands alone where he exists in terms of his productivity and his immense knowledge. I hold a small smattering of engineers in high regard but he is leaps and bounds ahead of that pack.
I think it's pretty clearly because those are almost always the people who will call themselves "10x engineers," and obsess about the idea of being better than everyone else. Good programmers don't do that for the same reason that "any man who must say 'I am king' is no true king."
[1] Although I read here just a few days ago that a 10x engineer is only ten times as good as a bad engineer, not 10 times the average. So maybe it hasn't always meant the same thing?
But there are people like Linus Torvalds, Satoshi Nakamoto (if they were one person), and those two programmers you mentioned. I doubt I could beat any one of them even if I replicated myself 20x.
I think, part of it caused by the wrong stereotypes of 10x engineers (for example, perpetuated by a VC in a recent Twitter storm) and it became a myth that people accepted. Another part is some people are new to programming and have not "encountered" these god-level programmers yet.
1. Super hardcore engineers like Fabrice Bellard, John Carmack or Linus Torvalds, 2. Engineers who bring insane amount of value to society, like Satoshi Nakamoto (if they were one person), and Markus Persson (founder of Minecraft).
So... At the start of this week I was trying to solve a bug that only occurred when someone had multiple browser windows open. I usually have just one browser window open.
The person who reported the bug did not mention that they had multiple windows open (and why would they). I got lucky when trying to reproduce it: my testing routine included giving it a try in Private Browsing, which meant opening another window.
If I had not done that, I would not have been able to reproduce the bug. How would such a dramatically more effective programmer have been able to reproduce that bug more quickly?
(Also note that the symptoms did not indicate anything relating to multiple windows. The report was simply: nothing happens when I try to run it.)
| my testing routine included giving it a try in Private Browsing
The 10X programmer (or in this case the 10X bug fixer) has a testing routine that sufficiently covers enough logical scenarios such that they're able to converge on the truth at a 10X speed.
It's basically the same reason why Guess Who is a game. Some people ask better questions that allow them to eliminate irrelevant details at a faster rate.
Had that not been the case, though, there would have been no indication to try using it with multiple windows open, as the error was a general "nothing loads", which is the result of an error condition anywhere in the code.
What I do know is that my programming style is to really dig into every new project I have to work with. Maybe not every part of an application, but everything relevant to the feature I care about. I'm an incredibly judgemental reader (this is sad for personal reasons) and as such, I come up with long lists of "I don't think this would handle that scenario." I don't have time to dig into them, but that list stays there in the back of my mind -- a vague sense that a loop wasn't accounting for a particular kind of array value, etc, etc.
Inevitably, months down the line, some of those bugs surface as actual things. I keep an eye out on tickets, or listen during stand-ups, and I only have to remember just enough of that problem to cut out the investigative time. Eventually I become the person everyone goes to to get them up to speed on any problems within any of the features I've worked in, over people with much more seniority on the team, or often even the people who are responsible for that project. This is also how people seem to always think I've been around twice as long as I have.
I'm not a 10x engineer -- I find it incredibly difficult to stay "on task" and that massively kills my productivity. But the way I approach codebases, outlined above, is just one of many tactics that can, in the right environment, make a programmer far more productive/useful than they would otherwise be.
I guess that's also an additional argument for not being the only person working on a codebase - it's far harder to read it judgmentally if you wrote it.
UI dev/QA is a bit different but this is how things typically go in sysadmin-land. A good engineer can hear a description of an issue and immediately pinpoint one or a few seemingly unrelated potential underlying issues to test. This is just a combination of experience and a deep knowledge of the underlying systems and processes that make things happen. The tough part is that this isn't something that's "teachable" -- some guys just "get it", others, while having superficial knowledge of the infrastructure, just can't seem to be able to mentally walk though a system or process and identify where the trouble might be originating from.
I don't think that would be possible, because there are literally hundreds of potential errors that could have the described behaviour as a result.
* Application code error should result in an error message somewhere.
* Application server configuration issue should occur for multiple users.
* Something happening to only one user should be caused by either their configuration or what exactly they were doing.
(And I'm sure there's more cases, but this is what's coming to mind offhand)
From another comment, it sounds like this landed in the third bucket - and better, nothing loading meant it wasn't something they were actively doing.
So it's some configuration specific to that user: Something user-specific from the database on page load, browser choice, add-ons, or - as you found - unusual (to the devs) browser usage, like zoom or multiple windows.
Obviously this isn't thorough and could be wrong depending on the situation (note I said "should" in the bullet points, not "will"), but it should help a bit. Even knowing possibilities like zoom or multiple windows is something you get from experience - now that you know it can be a problem and one of the ways it manifests, you'll know to check it next time you see something similar.
But 10x engineer or not, there's always he risk of running into the least likely problem - or, more likely, running into one of the problems in the long tail of individually very unlikely problems. It'd be nice if one could learn to lessen the impact of those worst cases, but I guess the primary thing one can grow in is making them less frequent.
They also might have looked at the code and said "oh hey, that won't work with multiple windows, I'll just change that".
In this case, I was also the person dealing with the person reporting it. Having had to close it with "cannot reproduce, won't fix" would have been a pretty disappointing outcome, and would make it really hard to discern between a 10x engineer and someone who's just bad at debugging...
I'm not quite sure I understand your point.
"Dramatically more effective" does not mean "dramatically more effective in every single scenario you can think of."
This one had me baffled for a bit, though, and I was fearing having to spend a couple of days on tracking it down - or having to give up. Sometimes those happen, and it'd be great if there are ways to have that happen less often.
What lessons about our architecture could we draw from this? What kind of test suite should we write?
Not to mention, to the much more numerous ranks of "1X" engineers, a 10X engineer, even a real one, is kind of a pain in the ass and hard to distinguish from an arrogant engineer.
The original "scientific" basis was a paper in the 60s (ish?) that found a 10x difference between the time taken by the best and worst programmers to complete a task. It excluded people who didn't finish the task at all.
The actual focus of the study was to study productivity differences between off-line (punch-card) programming and on-line (at a terminal) programming. Remember, this was the 60s.
The 10x finding was a side effect of a small study that has no applicability today. I'm not aware of any serious attempt to replicate the findings, probably because they're not very meaningful:
1) The 10x difference was between best and worst. This is a lousy metric. A better metric might be difference between best and median.
2) Productivity was defined as time for an individual to complete a small program to run on a single timeshare computing system. This doesn't tell us anything about modern real-world productivity, which involves working in teams, on distributed systems, with vastly larger development ecosystems.
In order for "10x" to be scientifically meaningful—to be anything more than another one of the stupid tribal wars programmers like to engage in—we would need to: Determine how to measure real-world productivity [1]. Use a better metric than best-to-worst. Pay for and conduct a non-trivial study.
Ain't nobody got time for that.
[1] https://www.martinfowler.com/bliki/CannotMeasureProductivity...
I submit to you that we would be having the same arguments no matter what study was done, because it could always be argued that whatever small-scale thing would be measured, and whatever metric was used, doesn't reflect the full complexity of reality.
We all know that some programmers are better than others. But actually quantifying that would not be in anyone's interests. For programmers, it would mean hard metrics to rate our performance, and people would be paid differently based on these metrics. "Bad" programmers, as defined by this hypothetical metric, would lose money and career opportunities. "Good" programmers would earn the wrath and envy of their colleagues. From a manager's perspective, hard metrics would encourage gaming the system and would generally not encourage team play.
So it is better off where it is. People who write code slowly can argue that they are really more productive because they take time for testing and collaboration and making documentation and making things legible, and that people who write code quickly are making unmaintainable messes. And people who write quickly have a prima facie case.
Or Salvatore Sanfilippo (antirez)
Or Guido Van Rossum
All also known to be very nice people. And that would deny they are 10x :)
Part of it is defensive posturing. I have encountered corporate developers who are hardly, or not, literate in their primary programming language yet see their capabilities as average or the norm. A productive person popping their delusional dunning-Kruger bubble may very well seem arrogant to them.
Carmack didn't exactly create Commander Keen all by himself. John Romero did some programming, and the level editors and other tools like the installer. Adrian Carmack did the art, Tom Hall came up withe gameplay ideas and level designs. Besides, Keen wasn't anything amazing in terms of a game, other than the fact that it was one fo the first popular side-scrollers on the PC.
In the end, Keen was a basic side-scroller. Of which plenty existed over the years. Shareware, hobbyist, and professional game developers were not in short supply.
Wolfenstein 3D and Doom. Again, Carmack wasn't the only programmer. Again, Romero wrote the level tools. Dave Taylor also had programming duties. Heck, id even farmed out the sound code! Wouldn't a true 10x developer bang out a sound library in his sleep?
Quake rolls around. This time Carmack has brought in re-inforcements. Mike Abrash for his vast knowledge of graphics coding and optimization, and John Cash for the networking side. Dave Taylor wrote the sound engine and some other things. Zoid ended up taking QuakeWorld.
Around the Quake 2/3 time, Carmack started to come into his own. They brought Brian Hook in help do 3D graphics, but Carmack created a level editor as his 'first win32 program', even though he eventually passed it on to Robert Duffy. Carmack was really doing a lot of things with 3D graphics and hardware at the time.
Let's not forget his side projects like graphics drivers and porting id games to things like the iPhone and SNES.
I'll end this by saying at the very least he had a huge hand in getting PC gaming going in the right direction. I also love his willingness to release the source code to their products. But was he a '10x programmer'? Maybe he was just really good.
Personally I feel PiD was a much better game than Wolfenstein, partly because of the adventure/RPG elements, partly because of the horror atmosphere. The UI was less immersive however. But the game certainly had very interesting elements. For example there was a level that was randomly generated every time. Some monsters could only be killed when frozen (using a special "blue crystal") otherwise they'd be invisible and be impossible to kill. It was possible to talk with dead human corpses using a "yellow crystal", etc… There was a special room that would drain the oxygen and only by speeding up the time somehow (perhaps using another crystal?) one could survive the room.
And some things Marathon certainly did better than Doom. For example it was possible to look up and down, the lightning effects were more impressive, there were some physics, etc ...
Of course the guy that wrote the Build engine (of Duke Nukem 3D fame) was probably at a more-or-less equal skill level as well.
---
[0]: https://en.wikipedia.org/wiki/Jason_Jones_(programmer)
There's probably legendary but unknown programmers at place like EA or Sony.
There are plenty of legendary gamedev engineers who are somewhat known, most of them hang out on Twitter (Carmack has a great Twitter account IMO)
I've only worked in the industry for a little over a year now, but I've heard some great stories from the senior engineers.
Yes. In fact, he is probably a 100x programmer.
It seems blindingly obvious that there are people out there who are just... dramatically more effective programmers, in a holistic net-value-to-organization/world sense. Fabrice Bellard and John Carmack, to name two that jump to mind.
And while I've definitely never worked with programmers of their caliber, I have worked with people who truly were an order of magnitude more productive than me, either in sheer quantity of quality output or by dint of their efficacy at creating tooling/abstractions/apis that made other programmers more effective.