Lots of ink has been spilled over this, and most books written about this make the mistake of comparing software development to manufacturing.
Software development is R&D, not manufacturing! Just ask your accountant.
Of headcount-related expenses in R&D, software engineering is probably the highest of them all. Makes perfect sense that there would be pressure on software engineers to estimate their work in terms of time.
But of course, any sane person would realize that “how long something takes” cannot be estimated in any sort of R&D activity, software or otherwise.
Unless, of course, there’s no R&D involved at all. Routine maintenance work and cosmetic changes can be predicted well ahead of time, as well as UI engineering, DevOps, infrastructure engineering, and data engineering which are more manufacturing-shaped than new product development.
A software development culture that values time estimates will inevitably trend towards manufacturing-like activities.
In other words, you’ll see “scaling” work and “redesigns” but never any sort of innovation.
Almost anyone who has worked in software knows that companies, as they grow larger, tend to innovate less and less. This is probably the reason! A focus on manufacturing-shaped activities, rather than R&D-shaped activities.
Real stupid, in my view. Your tax accountant and the tax authorities still consider software engineering R&D, so you’ve pretty much played yourself.
Not to mention that competitors — startups, indie hackers, and open source projects — who still do software development as R&D, will eat your lunch.
estimating tickets is my least favorite part of working as a developer