The problem I find is you get handed a legacy system and asked to give it new features. You have no idea what the code does. You have to narrow in on the tiny part the customer wants changed. They see the change as simple and easy. So they don't understand why you spent three weeks refactoring and adding test. They just want their new feature. As this goes on the code gets worse and the customer gets more unhappy.
My push back comes from the claim that DLLs are intrinsically different than npm code when it comes to security / complexity / etc.<p>In the bad old days you would find some random GLUT binary off of the Internet and stick it in your code, spend hours setting up linking, etc.<p>Pretending that was any better than what we do now, or pretending apt and npm are different in terms of trust and security is putting on rose colored glasses.
I agree with the author’s point that code is read far more often than it is written, and so we should prioritize readability by humans above other things by default.<p>However I think the concrete examples given are misleading. I’m grateful for the explicit dependency imports at the top of a file even when they increase the number of symbols I have to parse. The alternative seems to be a scripting environment where I’m never sure which package has monkey patched the global “echo” by default.