4 ms·

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 product

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.

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.