"No, it's less effort than that"

I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here.

However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy.

What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.

I think there's an important detail you might have left out of your 30 minute example: are you asking for how long the effort on the specific task will take, or what the time gap will be between right now and the moment it's delivered? Because in almost all teams both are dominated by the task waiting for something, but in the latter case it's especially true. Actual hands-on-keyboard time is usually a rounding error compared to coordination and scheduling. Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on. Not only that, but the team will be completely blind to the imbalance, and won't realise it matters.

> Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on.

What do you mean by "unintuitive ways of working"?

Here's a relatively small example: if you want to minimise lead time (which is almost always true) then one thing you don't want is for potentially releasable work to sit waiting for anything. That includes code reviews, if you have them on the route to production. So the right thing to do is usually for a PR being ready for a code review to be a drop-everything event for the person who's going to review it. As in, whatever you're working on right now, context switch out and do whatever is needed to get that code either over the line or bounced back ASAP so the person who wrote it doesn't context switch out.

This idea gets a lot of pushback because we have it ingrained (not unfairly, either) that context switches are expensive for the reviewer. But the safe assumption is that they're less expensive than delaying another piece of work that's already got a lot of embodied but unrealised value.

The intuitive assumption is that person waiting on the code review can pick up another piece of work and make a start on it so they're kept busy, but that falls into the trap of having too much work in progress. The result is then (usually) that the returned code review is now waiting for whatever they picked up. This is one reason why the intuitive way of working tends to having throughput that's barely ok, and latency that borders on ridiculous.