One big issue in developer productivity that seems less overlooked now is testing and test turnover time. I guess you could argue this falls under the responsiv

One big issue in developer productivity that seems less overlooked now is testing and test turnover time. I guess you could argue this falls under the responsiveness banner in the article, but that doesn't really discuss the extensiveness of testing and focuses mostly on things like review feedback. Testing in general is great because as your corpus gets ever larger you can be more confident that just running the testsuite is sufficient to catch regressions. That’s why large projects these days often require every behavioral change or bug fix to have new tests to cover the intended behavior and additional negative tests as well (eg don’t just test the new behaviour/fix works, you have to add tests for neighboring behavior as well). For many simple fixes the time to make tests is actually greater than the time to make the fix itself because you reduce the overall development time for the entire project in doing so. Over time that makes new development substantially easier and less worry inducing, but if you’re constantly adding new tests you get a new problem: eventually running all the tests just takes an absurd amount of time, even spread over all the cores (and depending on what your tests do it can make your computer unusable at the same time). I recall at some point the webkit bugzilla added bots so you could queue automatic test and commit flags, so you could locally test just the subset of tests you expected to be impacted and then rely on the automated infrastructure doing the full tests prior to merging which helped there. I vastly prefer that to "merge and rely on CI bots catching regressions" because it trivially leads to you having local checkouts that have failures and then you have to go back and forth verifying the local failures are existing in the tree, etc. In my experience that model seems much more prone to having regularly broken bots, and that breakage leads to normalization of broken bots and general distrust of local failures ("my change couldn't have caused this breakage, so it must already be broken in the tree and CI hasn't caught up") You get similar issues with build times and there isn’t really a solution for that in the C/C++ model of compilation - if the wrong header is touched you end up in a miserable near world build misery pit, and it doesn’t seem like there’s any real solution for that yet. This feeds into the last point as well: if you get local failures but you don't have confidence that the build isn't already broken there's much less incentive to rebuild the entire tree without your changes to confirm the "impossible by your change" regression is not in fact caused by your changes.