I think this is a big factor in estimation inaccuracy for really new programmers - but it is pretty well fixed by project managers following estimation rules of thumb - like double it and add five days... The bigger issue that I am less certain about being teachable is the experience side of things. I've worked in industry for a while and I know how long different sorts of patterns will take to write and what sorts of complications different sorts of add-ons will add to those numbers. Some projects are about where my naive brain fifteen years ago would put them and other ones are wildly different due to complexities that aren't visible in a surface level examination. Learning to sniff out those complexities seems to just take experience (not with every individual scenario - but it's a pattern analysis thing).

> I think it's because inexperienced programmers don't think about the "soft" costs of programming.

That's what the research has previously found[0] decades ago -- engineers will generally correctly estimate the part they are best at, but will either neglect or under-estimate other work. The old-school ways of dealing with this are canned Work Breakdown Structures and checklists.

This is not unique to software.

[0] van Genuchten, "Why is Software Late? An Empirical Study of Reasons For Delay in Software Development" https://web.archive.org/web/20160914040151/https://lab.cs.ru...

I do a fair bit of writing at work of various different types of things.

For stuff that I'm doing on my own? I can estimate pretty well. I know more or less how long the writing will take based on length. I'll allocate more time for research if I need to do more than a base amount. And then I add some slack in case I'm struggling with something, priority interrupts happen, or I'm just not into it on some given day. (Underpromise. Overdeliver.) It only gets harder with bigger projects. It helps that I'm quite fast compared to most people so even with significantly underpromising people are usually very happy with the estimate.

But where it's really hard is work that involves getting buy-in and input from a lot of different people. Those always take forever. (And at this point I pretty much know they'll take forever, a lot of which is just latency rather than actual active work.)

Programmers can also try to come up with reasonable estimates, only for management (product, middle or upper - or often all of them) to come back and assert that the estimates are off base and to "reconsider." Not much to do at that point but to give a lower estimate and hope it works out. If you make that your hill to die on as a programmer you will find yourself out of a job with only your integrity to keep you warm at night.