5 ms·
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 whol
by 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 agoGreat 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 agoI think it is more about understanding the problem and the structure of the data that goes with it rather than abstraction.
- jxub 9y agoYou'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 agoLinus 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 agoMy 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 agoYes, 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.
- elcritch 9y agoIt’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.
- tomcam 9y agoLuckily, the Git UI has progressed massively and has graduated to merely obtuse.