Yes, it is true coders have little time to code. But the author misses the primary cause: the ratio of library/framework code to self-written code.
In the old days (say, 25+ years ago), you would pick up a book -- a single book -- of the OS API calls, memorize, and start coding. Today, with github, it's as if everyone in the world were working on the same single project. Today, a developer needs to learn all these libraries that are coming out daily and how to work with them. In the old days, there was a lot of reinvention and co-invention of the wheel. Today, that is not allowed, because one has an obligation to "buy" (for free) instead of build because of a) of course, development time and b) more importantly, one gets updates/upgrades "for free" without having to invest (much) additional development time, and c) one's organization can advertise in the future for developers who already have experience with that particular library/framework.
To address specifically the reasons identified by the author:
- Deployment. This is big, perhaps even as big as the above. In the old days, deployment was copying a single executable file. Today, not only is deployment to various and numerous servers more complicated, but for the past 20 years we've had people dedicated to managing those servers, called sys admins, to handle all those non-coding tasks. Of course, coders end up doing some admin and admins end up doing some coding, so now for the past couple of years we have a new half-breed, the Dev Ops. The very existence of both sysadmin and dev ops are themselves acknowledgement that coding is a smaller percentage of the total work involved.
- Tools. The author spends most of the piece harping on this, and it's just totally bogus. We've always had source code control, editors, compilers, and linkers, and they've always been a pain at times to work with. But in fact, it's better now because you can find or ask about work-arounds and solutions on StackOverflow instead of calling up tech support at a closed-source vendor.
But this new development paradigm of the global github hive -- where we're all essentially working on and contributing to this one massive codebase that we all have to understand -- is what the author missed. The amount of custom code to actually code is small now, and the majority of time is spent figuring out how to get the various libraries and frameworks to work.