3 ms·

This article is more about generalists vs specialists, which is mostly orthogonal to 10x. The best point the author makes is "use the right tool for the job",

This article is more about generalists vs specialists, which is mostly orthogonal to 10x. The best point the author makes is "use the right tool for the job", but even there, making good platform decisions is merely table stakes. Also, it's not as sensitive as the author would like to believe. To take his example, using Sinatra instead of Rails is simply not that big a deal unless you are specifically memory-constrained. 10x itself comes from the long-term observation that some programmers are just dramatically more productive than most. It doesn't come from one trick or technique, rather it's a combination of strong modeling, internalizing the high-level goals, and being able to mentally move through the layers of abstraction very fluidly. Where the 10x comes from is building elegant models that bypass whole rafts of problems and unnecessary code that lesser programmers would create. It's more about the code they don't write than the choice of tools.

deleted 9y ago
[deleted]
kenforthewin 9y ago
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.
- dasil003 9y ago
  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.
  - jxub 9y ago
    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.
    - CyberDildonics 9y ago
      I think it is more about understanding the problem and the structure of the data that goes with it rather than abstraction.
      - jxub 9y ago
        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
  - hisham_hm 9y ago
    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.
  - SteveJS 9y ago
    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.
    - dasil003 9y ago
      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.
- KKKKkkkk1 9y ago
  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.
joshvm 9y ago
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.
- jimbokun 9y ago
  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.
  - arpa 9y ago
    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.

deleted 9y ago

[deleted]

kenforthewin 9y ago

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.

dasil003 9y ago
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.
- jxub 9y ago
  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.
  - CyberDildonics 9y ago
    I think it is more about understanding the problem and the structure of the data that goes with it rather than abstraction.
    - jxub 9y ago
      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
- hisham_hm 9y ago
  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.
- SteveJS 9y ago
  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.
  - dasil003 9y ago
    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.
KKKKkkkk1 9y ago
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.

joshvm 9y ago

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.

jimbokun 9y ago
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.
- arpa 9y ago
  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.