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.

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.

[0]: https://bellard.org/lte/

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.

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.

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)

[1]: https://en.wikipedia.org/wiki/Pathways_into_Darkness

[2]: https://en.wikipedia.org/wiki/Marathon_(video_game)

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.

This is a textbook example of a bad system with a single failure point/bottleneck. One way to be considered "10x" is to be the only person with the know-how to keep a critical function afloat.

We really don't learn from history. Eli Goldratt wrote about this in his book The Goal--publication date 1984. Context was manufacturing but it's easy to see the principles at work and consider them in other contexts.

Gene Kim, George Spafford, and Kevin Behr wrote about this in a DevOps context in The Phoenix Project--publication date 2013.

These are just two examples of individuals who wrote books with mass market appeal that read like novels to illustrate their points. Many, many other people have thought and written about how to avoid building bad systems. And yet still, in 2019, as this 10x discussion flares up again, it's a myopic view of the individual without a scent or sight of talking about bottlenecks or systems.

Sometimes I'm in awe of Startupland and Tech World's accomplishments. Other times I'm in awe of what it doesn't even know it doesn't know.

https://en.wikipedia.org/wiki/The_Goal_(novel)

https://www.goodreads.com/book/show/17255186-the-phoenix-pro...

I think often (and in this article) an organization has zero people with the know-how, and then someone struggles and figures things out, and now they have one person. That one person might be someone who has figured out how to deal with a difficult stack, or might be the person who has built that stack themselves – either way, they've done something valuable because they are handling something that is critical.

The next step – spreading that knowledge, or making the knowledge more accessible, or making the system more usable – is important, but it's not wrong that the organization has ended up this position. It's part of a maturing process. And we shouldn't shit on the person who brought the organization from zero to one, just because they aren't the person fully equipped to bring the organization from one to many.

Very good point.

There's an underlying principle here that I didn't say. Management is responsible for the system.

Dead simple when written out, yet infrequently shown through managerial actions.

If you have decent management, they'll set up firewalls between you and the people requesting work. Trainees or people of some experience but perhaps not as quick under pressure. Reduce the burden, start automating what can be automated. But if that's absent, if the pressure remains. Enjoy the glory, but look for an exit. You're one vacation away from returning to a layoff.

Enforced vacation time is a great way to figure these things out prima facie.

As employees, we all know that 'unlimited vacation time' is just a code for 'no vacation time' (with rare exceptions). But companies get into that trap too. When they red-line their employees that hard, they expose themselves to unncessary risks. People get sick, they have tooth aches that need mending, they get jury duty notices during a crunch, their folks go into the hospital, etc. Let alone actual in-house issues of burnout, server issues, internet connectivity.

I worked with a shop that was dog-friendly once. They had to get fumigated every year or so, as the pooches would invariably bring in ticks and bugs. That was four days they just could not work at the office each year, with a pretty nasty decline in work enviroment quality in the lead up to each fumigation.

Enforcing vacations causes the firms to deal with these issues ahead of time. Vacations have been well studied and, especially with knowledge workers, improve employee productivity (generally). But they also act as vaccinations towards unseen workplace issues and black-swan events.

This is related to the idea of JIT and low-inventory in Lean. By reducing inventory, it allows problems in production to be revealed so they can be addressed. Consider a simple 2 stage process. The first stage is down 50% of the time on average:

  A -> B

In Lean, you pull inventory into B only when needed (realistically you'd have some lead time, of course). You maintain a modest buffer to accommodate that lead time. If A can't produce in time, instead of growing that buffer permanently, you address the issues with A. Identify the failing components in A and find a more reliable replacement. Maybe there's not enough people trained to operate A so you cross-train people. Maybe you buy a second system (cheaper, lower capacity?) that can do what A does to shift the burden, or you find another machine that can be conscripted and used to make the same things that's only rarely needed for its primary purpose.

People who operate at 100% capacity and are your "heros" are similar to A. Everything seems great as long as they're there, but once they're gone (even for a day) they're noticed. By capping overtime (or eliminating it), by encouraging vacation time, you can find out who is critical to your business processes, and start shifting the burden (because it's an obvious pain point).

Anecdote: We had a guy who wasn't officially IT, but had been doing IT for our build and other dev systems, it wasn't his main job. He was gone for a vacation or business trip for a week, on Monday the systems went down. Nothing was accomplished until he returned and fixed the problems because no one else knew how to do that work. He was a liability for the team and business. This happened on more than one occasion. Management loved him because they didn't recognize the causal relationship between his leaving and things being in a failing state (didn't happen everytime, he wasn't causing the failures, but his absence meant the failures were noticed and not addressed quickly).

Control your "WIP" (work-in-progress or work-in-process) better, and you'll see work piling up in specific places. Just track it on a board or create a helpdesk ticket system that people have to interface with. It'll make all these pain points obvious so they can be addressed.

The thread was written by a VC on what he thought a “10x Engineer” to him was, and he grossly summarized pretty much the opposite of that. https://twitter.com/skirani/status/1149302828420067328?s=21

Here's an actual quote from the thread: "10x engineers don't hack things. They write quality code and know exactly how the code has to evolve, and have a mental model of overall code structure. They write at most one design document, and the rest is in the code."

The thread wasn't particularly crazy as far as Twitter takes go. I think it only went viral because of tweet #3, the one about background colors and keycaps.

The whole meme about 10x programmers writing terrible code very fast must have come from somewhere else.

> 3. 10x engineers laptop screen background color is typically black (they always change defaults). Their keyboard keys such as i, f, x are usually worn out than of a, s, and e (email senders).

It doesn't mean doing 400 hours of work a week, which isn't actually even possible. It just means using your time so much more effectively than others that it just seems like you're doing the job of 10 people.

The ultimate "10x" engineer, to me, is Peter Norvig. (Maybe a 100x engineer?)

For fun, he knocks out a spell checker on a plane ride:

https://norvig.com/spell-correct.html

In very concise, well documented, easy to read and understand code, with good performance.

This isn't because Peter doesn't have to look at documentation or has a black desktop background. It's because he can look at a problem and come up with elegant and creative solutions other engineers wouldn't even think of.

This out of the way reply to a comment on a post that's a reply to a twitter storm.

This here, this is a major issue I have with 'news'. We are many times busy discussing crap, which is well defined and easy to understand. But the mundane, easy explanation fails to be bait worthy.

Instead what gets picked up is the most extreme, strident and far out explanations. And these seem to dominate public commentary.

jimbokun summarized what a 10x engineer is, in an off hand comment, better than all the fuss that started his comment.

Also, "more talented" is a much milder statement than "much more productive", which in turn is a much milder statement than "10x". (The first two, as well, are not saying the same thing. Talent != productivity.) Nobody disputes that there is a distribution of talent or productivity among software engineers. People dispute the magnitude of the standard deviation of that distribution.

Going to your Olympic swimmer example, the number of people who qualify for the Olympics in swimming is a small portion of those who try out, which in turn is a small portion of those who are involved in competitive swimming at all levels. Thus, the number of Olympic-level swimmers relative to the overall swimming talent pool is tiny. I don't think anyone disputes that there are a few dozen, maybe even several dozen, people who are several standard deviations better than the average software engineer. What they dispute is that there are companies full of them, or that trying to hire them is a viable strategy.

This isn't to say I fully disagree with your point, by the way. I'd rather use the analogy of a TV producer, or a movie production, or a band. It's creative output, there's tons of variation in the level of natural and practiced talent, it's highly team based, and the work product is very much a knowledge product. But, even there, differences remain between something you have to use and something you can consume for pleasure.

How about industrial design firms and elite designers? Well, now we're cooking with gas -- when it comes down to it, engineers are still ultimately designing systems that either are dependencies of other systems that people directly use, or are those systems themselves. What makes someone 10x more productive? Is it that they individually produce 10x more output, or that they understand the nuances of the constraints 10x better, or that they're able to make the engineering lifecycle 10x more effective, or some combination of all of the above? I'd say the latter. In that way, there are almost certainly outliers that are more productive than the mean.

And, in my experience, that comes from a combination of individual competence and team/organizational based leadership ability. It's a far cry from the savant 10x individual contributor that the 10x meme originally came from and which many folks across the industry now (rightfully, in my opinion) critique.

I've been a "10x engineer" and I'm not sorry. The difference is, it's not the 10x savant individual contributor. I've made entire organizations 10x more effective, but fundamentally, that was because I learned how to be a good multiplier: how to help people out, help them grow, unblock procedural bottlenecks in a lasting way, resolve misalignment between different divisions in an org, refine a product that was missing the forest for the trees, and so many other things. But that did not come from me being some kind of natural genius, or more "talented" -- it came from me being persistent, and never really being satisfied if I thought things could be improved. It came from me doing that over a long enough period of time that my cumulative output and multipliers ended up indeed 10x-ing things. This is the kind of "10x" engineer that I believe most engineers can become -- not easily, but doably. I've built teams and orgs consisting of these kinds of engineers. And, they'll eat your 10x savant contributors for breakfast.

How does the old saying go? Culture eats strategy for breakfast? It seems trite, but it's always rung true in my experience.

So, here you perfectly describe a 10x middle manager. Or just a "good" middle manager, because I agree this 10x business is kind of silly.

I will never understand why people take all these soft skills unrelated to programming and say they are more important to a programmer than skill at programming. It's not that these skills are undesirable. It's just that, to continue the sports analogies, it is like saying that it is more important for a basketball player to be fast and be a good team player rather than be skilled at shooting and blocking.

If anything it is the other way around, people with good soft skills and bad technical skills are an absolute menace and plague if they try to get involved in anything technical. They have no idea how much they screw up everything they touch.

If you aren't a programmer, and you're a manager of programmers, then fine. A coach needs a totally different skillset than a player and you can be a fine coach even if you are a mediocre player.

Who said I was a manager as I was developing and applying these skills? I was doing this as I was still top of the pack as an engineer. I will never understand why people take all these soft skills that are completely required to do the job of engineering and say they are not part of the job of engineering. What is it with the sports analogies? They're fundamentally inappropriate and imply a deeply reductive conception of the craft of software engineering. You're doing something with a goal far more complicated than "the team with the most points wins".

Moreover, you're drawing a false dichotomy. People with the technical skills to really be highly productive engineers always have the soft skills too. They are both required to sustain high productivity.

But please, don't tell me I'm not a programmer. I'm an excellent engineer, and I've always been near or at the top as an IC. But, that's not in spite of my soft skills. It's because the two create a feedback loop that helped me level up and run things more effectively than engineers that overspecialized on one or the other. And again, the best ones I've worked with have been the same.

If you've seen such engineers, then that's one thing. But if you haven't, implying that you even need to choose, or that the best engineers don't have both -- it's specious. It's something you think must be the case because you don't have a more exhaustive set of data and experiences to draw from. And that's okay! But then, one would hope you'd at least be curious about it rather than dismissing it.

These engineers are not unicorns or mythical creatures. They're competent professionals that take every part of their job seriously. They're the kind I prefer to work alongside and hire.

Also, I think it's in poor taste to make this kind of "confession" or "apology" because sincere apologies can have weight and meaning, and this cheapens them. By arrogating the responsibility and the apology to themselves, this person is protecting the people who created the situation. By blaming his own personal deficiencies, he is obscuring the fact that the business chose (probably intentionally) to benefit financially by relying on a single overworked engineer instead of a team.

Yeah, yeah, I know we're all supposed to claim ownership and responsibility for everything at all times, but sometimes it's appropriate to blame somebody else.

https://hackernoon.com/10x-rockstar-ninja-wizard-vampires-f5...

"Ninjas are nameless, faceless mercenaries. The ninja’s job is to create mayhem for the highest bidder. The ninja shows up in the dark of night, uses mysterious powers and ruthless violence to create disaster, then disappears in a puff of smoke.

Ninjas are nameless, faceless, heartless, merciless enemies.

Are you sure you want to hire them to work on your code?"

"what makes a wizard a wizard is that they use magic. And unless you’re born with it (Harry Potter), or study ancient and mysterious tomes, you will not be a wizard. Only wizards can understand what other wizards do. Unless your whole team is wizards, you might want to reconsider the idea of using magic rather than proven tech in your code."

My ex-employer was an abusive(msp) employer who couldn't hold onto senior staff. The organization became so tremendously bottom heavy with people just out of school; I would literally have people lined up in my office waiting to talk to me to get help.

I was practically the only person who wrote documentation. I was literally the only person who wrote how-tos. MYself and only 1 other person was the only people to even push positivity. The place was so toxic that everyone was looking for reasons to complain. I'd have people come into my office to hide from dispatch/work.

Long story short, I reported harassment and got fired the next day. Over the next 6 months that place shed over 20 people out of 30 staff.

The workload I took on doing 60 hour weeks and 24x7 on-call had to be given to others. Everyone else said that was enough and found new jobs.

That company kind of imploded as there was about ten working when I left and now there's three guys left trying to get the work done. Luckily their focus has finally changed and tightened and there may be some good stuff brewing up so I'm cheering for them. Still missing working with those guys, though.

I had to babysit coworkers who were impossible to work with and had been banned from multiple customers because they had temper tantrums toward the client.

I got so tremendously burnt out and when I started realizing it and analyzed what's going on, I had a guy harassing me, I wrote up an email detailing the shit the guy was doing to me and the day after i report the harassment I got fired.

Like in university, I could 10x nearly any other student at programming... almost a direct result of the fact that I actually read man pages, documentation and the longer stack overflow posts.

And people would assume I was just somehow inherently good at programming.. but no, I’m awful at it; I just learned to read.

And no one will believe it

Will always happen if the problem is complex and the org small enough.

If you do it voluntarily, you are probably not that a great engineer. But even the good ones fail at some point.

Finding someone who can replace you is very difficult in average mid-sized cities. And most problems aren't even restricted to the extremely pluralistic software environments we have and additionally need experience in specific domains.

He doesn't understand what a 10x is. Not even from the tweets.

This isn't to crap on the raw ability and talent of a 10x -- I'm massively envious of that ability! -- only to point out that with disproportionate output comes consequences.

"I wasn’t just the most important cog in the machine – I was the machine. Nothing went forward unless I was doing it. And that’s not scalable at all."

10x'er vs. Scalability of 10x'er (when/where/how 10x scales, when/where/how 10x does NOT scale, etc.)...

An interesting subject for future business thought leaders, is it not?

I've moved up to Network Architect and I'm working hard to replicate my knowledge out to small network team so I don't have to work tickets anymore.

One of the reasons for the promotion is the understanding I have across categories- firewall, voice, VPN, APIs, Proxy, MPLS, layer 2, and so forth. Unfortunately, that really does make me more effective troubleshooting than the specialists on the team, even fairly experienced ones. But it also makes me most valuable at an architectural level. So I'm working hard to make sure that everything is documented and their is 2 deep understanding of the things I worked on so that I can be free to build up the future.

The irreplaceable man/woman can't ever get a real promotion because they'll be stuck at whatever they are doing today. Being valuable and a 'bargain' at almost any price is much better.

I've _never_ heard of a 10x salary difference for engineers. If you are a 10x engineer, that strongly suggests you're giving away free productivity to your boss.

If you own your own company, great! Even better would be to give 2x of your productivity to your boss, which is probably more than you're being compensated for, and use the 8x leftover for your own enrichment.

But there is almost literally no way that you are being fairly compensated if you really are 10 times as productive as your average engineer.

A Netflix engineer was on HN the other day claiming they make 800k and work from home.

> But there is almost literally no way that you are being fairly compensated if you really are 10 times as productive as your average engineer.

(Assuming they exist, of course) I'd wager if a 10x engineer was involved in a mundane business, they would be 10x without giving 100% of their time. Or rather, they'd give 100% of their time sometimes, and 20% of their time more often.

A true "10x engineer" would also care a great deal about documenting stuff, communicating that to the team, and be wise to ensure that a good technology system should not have a single point of failure (either technical or human). The fact this so-called 10x engineer made himself a single point of failure goes against the basic principles of engineering.

So, I put a funny slide - if any of you get inspired by my talk and do something great, then you are looking right now on this unicorn 10x or maybe 100x eng.

The bottom line, helping others will make you 10x, not putting yourself as a bottleneck everywhere.

He claims to have not been liked while a 10X-er, but pivots successfully into founding an inter-personal-relationship heavy company, whose U.S.P. is decidedly not engineering, and we're all to believe his self certification of the 10X moniker, if such a thing even exists.

But, programmers can tremendously improve their own efficiency/output by building their own collection of libraries and toolkits.

Pretty much by now, we all have seen more or less the same things. So if we have a vast archive of tools, our productivity can be crazy high.

I almost feel like sending this to a "10x Engineer" in my team. (Its in quotes, because I do believe in the 10x concept, minus the negative baggage which it is associated with, and as the article shows, also can be true.

In other words, you needed to hire 10 people with individual skill sets to match one Generalist who understood the entire stack.

The term appears have morphed and skewed over the years. Regression toward the mean has shifted the expectations for "average" programmers.

Today, a "10x engineer" to me is someone that is very technically competent but is _also_ competent with people and business needs.

The latter is much harder to find than the former, IMO.

I say this as someone who's both been a single point of failure at times (and learned my lesson) and someone who's had to clean up after piles of "clever" code that someone left behind when they got hired out somewhere else.

James Strachan brought us Camel and Groovy. That's pretty good.

Gavin King had Hibernate and Seam. Not too shabby, either.

There are definitely people who are very good. To me, having more than one runaway hit is a good indicator.

But there are a very few of them.

On the contrary, I think, there are quite a few of them still. Just look at people who created Python, Emacs, Vi, Sublime Text, Charles Proxy, Nginx, Apache Httpd. And this is just scraping the surface of the useful software in the OSS.

May be percentage wise, they are less. But even a .1% of millions, still makes it in the 1000s. And lot of others who perhaps have the potential, but sadly never realize it.

Neither the author nor the toot thread that inspired the author seem to have the first clue what the term means. And it would take, what, six words to define it?

When I opened it in IE to see it without my adblocker I also got an alert about trying to download or run a javascript file. Probably incompetence on the ad network's part (it doesn't look any more malicious than your average ad network tracker), but prompting people to download random 3rd party js files isn't a good look either.

https://i.imgur.com/gIoJY7v.png