Yeah, the status-quo for me for several years has been "I don't know" because most things I build end up needing to debug something I don't have an immediate answer for, or construct something new, or talk to a new team, or find a new lib, or change a new setting, or migrate to a new platform. If I'm repeating work I'd done many times before, that's something that should be made more flexible and automated so I don't need to do it any more. (these of course exist, but you're pretty easily replaceable if this is a super-majority of what you do daily)

So my estimates are pretty much always "if it's well-built, documented, and fits what I expect, a week or less. If not, up to 2 months or more, but I should know more in 2 weeks". Getting a more accurate estimate quite often means spending as much or more time investigating than it would take in the optimistic case, so usually the answer becomes "give it a shot and we'll decide again later". Sometimes I have good news, sometimes not.

---

We sit on top of millions of lines of code, changing faster than we can read much less understand. You cannot know it all, nor is it worthwhile to try in the vast majority of cases. Poking into new territory is common, and the ability to do so effectively is a super important skill.

Code organization (part of Architecture) matters a lot here. Especially in large code bases. Software is meant to be “soft” or pliable easily. To do that, one should be able to alter a module without having to understand the whole system. If a small task takes too long, there’s a problem with the software architecture or code organization.

I think GP's "millions of lines of code" references the code that runs all the systems outside of your particular org's architecture.

Got it. Better to stick to tried and tested “boring” stuff and actually code small functionality yourself than chasing a thousand line library for trivial stuff.

At work, someone used a 3rd party library to send stats to a server in json format and “standardized” on it. 100s of developers had to now learn this new library and it’s APIs and one bug caused everyone a bit of hassle. It probably made the original dev’s job just a little easy but made it a bit hard for everyone else. These things do happen. The point is to learn from this and make better decisions over time, not give up and say we can’t get better. Trying to provide an estimate forces you to think more carefully and become better over time.

A poor library choice or two is not even 1% of the systemic dependencies any system has if it's working at a reasonable level of abstraction.

> "not give up and say we can’t get better"

Not sure why you feel the need to state this straw man? That is not my opinion, nor do I think it is the GP's.

It was not a counter argument to anything per se. Just pointing out that even with episodes of failed estimates, there is reason to continue estimating.

Let me clarify: when I said “they are not qualified for the job” I meant they are not qualified to produce the estimate yet. They can always go back and learn what’s needed and come back with a more educated estimate (still an estimate) or they call it out as a risk item and address it ASAP. More often than not, this is because they are not ramped up (manager’s or team lead’s fault) - why else would you ask a complete newbie, regardless of seniority, to estimate?