This article is uninformed nonsense, as per usual on this topic. When the 10x study was published, it referred to tested, quality code (and assembly code, at that). Reminds me of another article from a while back where a 0x engineer who spent his time on other maintenance, code reviews, and testing without logging his work one sprint made similar complaints about wanting productivity, as if the rest of his team thought freeing up their time to develop their task was reducing their velocity somehow. At best this type of glorified blogspam is clickbait, and at worst it suggests a strange desire to disregard hypercompetence instead of trying to learn from and emulate it.
And besides, if it genuinely (again, clickbait) takes you 100x longer to code something with tests as it does your colleague without them, there might be something deeper going on there. It could be worth trying to learn from them anyway, even if their code has a few bugs you would've caught.
Speed up gains in development are not just a matter of how fast a coder can achieve a task compared to another worker, but how a certain choice of architecture can enable these gains to be collected again in the future for anyone working on this codebase. If you managed to make a certain task completable 10 times faster and this task will be repeated n times in the future (for instance implementing an API route on a server), you end up with a "complexity" of n versus 10n. Of course it requires making code investments and these decisions should be made by assessing whether it is worth it with respect to n (whether YAGNI). The true "10x" improvements are to be found in the compilers and frameworks you use, now the question is whether your 0.1x colleagues would be comfortable working with tools whose implementation overwhelms them but still allow them to get a 10x speedup.
Again, my understanding is that the 10x study was done on reviewed devs writing necessary and best-practice code in a cooperative setting with the same tooling, so this is still irrelevant to discussing the topic. Of course no one who wants to encourage velocity thinks you shouldn't invest in tooling that will automate long tasks for you. We should learn and cheat. My irritation is with suggestions that there's nothing serious to learn, not that I think there's nothing to cheat on, which is an unconnected topic anyway.
Comments
This article is uninformed nonsense, as per usual on this topic. When the 10x study was published, it referred to tested, quality code (and assembly code, at that). Reminds me of another article from a while back where a 0x engineer who spent his time on other maintenance, code reviews, and testing without logging his work one sprint made similar complaints about wanting productivity, as if the rest of his team thought freeing up their time to develop their task was reducing their velocity somehow. At best this type of glorified blogspam is clickbait, and at worst it suggests a strange desire to disregard hypercompetence instead of trying to learn from and emulate it.
And besides, if it genuinely (again, clickbait) takes you 100x longer to code something with tests as it does your colleague without them, there might be something deeper going on there. It could be worth trying to learn from them anyway, even if their code has a few bugs you would've caught.
Speed up gains in development are not just a matter of how fast a coder can achieve a task compared to another worker, but how a certain choice of architecture can enable these gains to be collected again in the future for anyone working on this codebase. If you managed to make a certain task completable 10 times faster and this task will be repeated n times in the future (for instance implementing an API route on a server), you end up with a "complexity" of n versus 10n. Of course it requires making code investments and these decisions should be made by assessing whether it is worth it with respect to n (whether YAGNI). The true "10x" improvements are to be found in the compilers and frameworks you use, now the question is whether your 0.1x colleagues would be comfortable working with tools whose implementation overwhelms them but still allow them to get a 10x speedup.
Again, my understanding is that the 10x study was done on reviewed devs writing necessary and best-practice code in a cooperative setting with the same tooling, so this is still irrelevant to discussing the topic. Of course no one who wants to encourage velocity thinks you shouldn't invest in tooling that will automate long tasks for you. We should learn and cheat. My irritation is with suggestions that there's nothing serious to learn, not that I think there's nothing to cheat on, which is an unconnected topic anyway.