This article makes me think of the woodworker's dilemma. You might start working with cutting, planing, joining and finishing wood because you want to make a chair or end table, and you like the idea of learning to do it yourself, maybe saving some money, or at least getting some extra tools out of the process, and having some pride in your work. But before you know it, you've spent 4 years accumulating tools, but more importantly, getting really good at making jigs, shelves, etc. to organize your tools and make your hobby easier and more enjoyable. In fact, you spend 90% of your time building tools. You do this not because you have to, but because you enjoy it. And because the brain makes it so easy to think of new ways you can use the skills you're building to make more tools in a virtuous cycle.
When you actually build a chair or end table, you complete the project, and you do enjoy the fruits of that labor, but there's no real cycle there. It's just an ending.
Software developers might fall into a similar trap, being so enthralled with building their own tools, writing libraries, designing and implementing frameworks, creating processes like CI/CD that obviously make the whole software development life cycle better... but of course it's largely an internal cycle that's more interesting than a lot of the end results of software that might actually benefit business (and measurable productivity.)
When you actually build a chair or end table, you complete the project, and you do enjoy the fruits of that labor, but there's no real cycle there. It's just an ending.
Software developers might fall into a similar trap, being so enthralled with building their own tools, writing libraries, designing and implementing frameworks, creating processes like CI/CD that obviously make the whole software development life cycle better... but of course it's largely an internal cycle that's more interesting than a lot of the end results of software that might actually benefit business (and measurable productivity.)