The issue was that the dev didn’t consider why an imperfect estimate would be useful. So they didn’t understand problem solving at a basic level. Engineers not prioritizing what they work on is not a good idea. Especially when the particular ticket was something like adding a feature to an iPhone app.
in my company we actually do estimate work and many people are so bad at it. however we learned from that and our trainees need to track how much time they spend on issues and then we talk about that after two weeks, so they get an understanding why something takes x or y and they can learn to estimate work.
estimates do not need to be perfect, but we encourage everybody to estimate more time that they think instead of less. so for the estimate they need to think about the problem and do not code like monkeys without any kind of plan on how to fix the specific problem/task.
Right, the goal of estimating in this since isn’t to have perfect estimates, but to get people thinking about how much time it takes.
It’s also important to not “grade” people on their estimates or treat them with great precision. Just an ongoing rough ballpark helps with planning. Although oddly I found that estimates got better over time.
At the end of the day: technical problems can have hard constraints that dictate the usefulness of your product and the people who have the skills to investigate and fix them should be dedicated to using those skills to fix such problems. Worrying about users, funders and other teams is what Product/Project and Engineering managers are meant for.
I do agree with you that it’s not practical to spend infinite time on fixing a problem. But it’s not strange for an engineer to think that way; in fact engineers who are willing to dig deep and at least root cause the issues (if not outright fix them) are very valuable to have.