I get the idea of generating less technical debt. That's important. And completely separate from the fragmentation of titles/jobs within CS. Part of 10x productivity is being great at a wide variety of tools, not just excellent at one. And yes, part of it is employing good code practice and data models and such.

You're missing my point. I'm not talking about "good code practice and data models and such". I'm talking about how you digest and model the problem as a whole, that is where the 10xer shows his quality.

Consider git vs svn for example. Linus was familiar with Subversion and its predecessors (CVS, RCS) before he created git. He knew that that model of change control was inherently flawed, and that he could create a better base model. According to Linus, he built the git core in 10 days. Even though svn had decades of a head start and tens of thousands of hours put into it, it only took a few years for git to rapidly supplant svn. The reason? Because the problem was modeled better. After 7 years of using Subversion, I was still getting bitten by weird bugs, had a terminal fear of branching, and general uncertainty about how the internals works. Within 1 month of using git, I had a better mental model of how it worked than I did about svn. Looking at the ecosystem around git now, especially considering how user hostile the porcelain CLI is, is a testament to that original core Linus created in a remarkably short amount of time.

Another example in the Ruby world is how Yehuda Katz and Carl Lerche created Bundler. Rubygems already existed of course, but there was no way to freeze dependencies, and as the Ruby ecosystem exploded in the mid 2000s we rapidly entered our own version of the famed "DLL hell". These guys came in, and over a relatively short period of time, hammered out a solution for freezing gem dependencies, layered over Rubygems (whose antagonism they often faced), addressing a huge range of use cases, and got it adopted as a defacto standard. To this day, Python has made 3 or 4 attempts, none of them as good as Rubygems. NPM, which started after Bundler was already out, was inferior and is only approaching in the last couple years with Yarn.

These are the type of things 10x developers do, they build systems that pay huge dividends by their elegance, things which others can build on. Neither one of these examples has anything to do with using a "wide variety of tools". Learning multiple tools is just something that happens organically through your career in most cases, but it's far from necessary. You could specialize entirely in C++ for your entire career and while there are lots of problems it wouldn't be a fit for, but that doesn't preclude being a 10xer.

My understanding is git’s origin was in reproducing and extending the functionality contained in Bitkeeper due to a crisis with the licensing. The apparent story of git being a exercise of Linus the 10X programmer digesting and re-imagining ‘SVN’ in 10 days seems non-historical. I think a good deal of the git vs SVN ‘10X special sauce’ was done by the company behind Bitkeeper, a tool already used for kernel source control. Linus built the core in 10 days because the problem was clear and the DVCS solution was already in use via Bitkeeper.

Yes, I'm aware of that, my intent was not to suggest that Linus invented the DVCS from whole cloth (DARCS preceded git and hg by several years). The point is that moving to an open source VCS had been a topic of discussion for years leading up to the Bitkeeper crisis, and Linus had been very vocal about the unsuitability of the mainstream options, going so far as to say email and tarballs would be preferable.

The fact that Bitkeeper precipitated git does not really diminish the accomplishment in my eyes. Remember, Bitkeeper was closed source, and the licensing crisis was precipitated by reverse engineering of Bitkeeper in the broader kernel developer community. Linus specifically set out to build a replacement from first principles and he built an incredible foundation in a very short amount of time. If it was a straight clone that would be one thing, but in reality git is its own thing, and fairly par for the course in terms of a top engineer leveraging past experience to build something better.

It’s good to point out that Linus appeared to nail the core data structures for a successful and performant DVCS in those 10 days. The git UI for the longest time was fairly obtuse yet that seems to have mattered less in this case than that the core foundations were solid as your comment points out.

Luckily, the Git UI has progressed massively and has graduated to merely obtuse.

It takes well planned effort to remain obstinately obtuse as thengit UI does. ;)

Joking aside, I only use a subset of git functionality which generally suffices. The part that keeps me happy is that the tools for detecting files renames, and diff’ing tools continue to improve and become very useable (despite the diff options being quite archane at times). There was an article a while back discussing how git’s straightforward approach of storing the original data blocks allowed the continued improvement of the diff and rename tracking tools in contrast to others like mercurial or bazaar which tried more sophisticated delta (?) techniques upfront. Wish I could find that article again, but it would support the parent’s premise that choosing the right models and framework make a 10x programmer.

Great response.

Being a 10xer means being fast at finding the right abstraction within a reasonable time frame which allows to further diminish time constraints that are part of the execution.

In other words, think (well) before you act.

I think it is more about understanding the problem and the structure of the data that goes with it rather than abstraction.

You're right, abstraction is more important at API level to enable other developers grok the code faster. But the problem is also solved better at the right level of thought, reusing libraries where useful and dropping closer to the metal when perf requires it

Linus was a user of BitKeeper, a proprietary distributed VCS that already implemented that improved model. Linus did not conjure the Git model in 10 days.

Less technical debt? I always thought that you get to 10x by jostling with your coworkers for the highest-impact work, and then plowing through as fast as you can, generating as much technical debt as necessary for your 1x colleagues to clean up. At least that's how I've seen it work.

The specific examples in the post seem to boil down to architcture which is ultimately a managerial decision. Either the PM knows enough, and is respected enough, to dictate how the project will look, or they cede to the expertise of their team.

To be bloody minded, what happens if 10X says: "Why use RoR for an API-only app with no database when you could go with Sinatra? Or even serverless?"

And all the <10X devs on the team say "But we know RoR."

Then it's a cost benefit analysis of whether retraining the team to adopt a 'better' tool is worth it. Sometimes it's blindingly obvious that you shouldn't be inventing a wheel when there's a wonderful library that'll do it for you, most of the time it's not so simple.

Then part of the skill of being a "10x" developer is avoiding working with incompetent PMs and devs. There is no way to achieve outlier successes in an environment like that.

What if simple success would do? I think that delivering an high quality end result within budget and scheduke is much, much more important than being übercompetent 10x developer who only works alone.