undefined | Better HN

0 pointsprepend5y ago0 comments

I once worked with a developer on a relatively small team of 10 people or so (3 other devs) who said it was impossible and pointless to estimate effort for tasks.

He said that instead a task should be assigned to him and he will work on it until finished, checking in once a week to see if it’s done.

It was the weirdest thing so we explored it a bit in a planning session and followed his logic that if we had four devs does that mean we only assign 4 bugs a week? What do we tell the users who submitted the bugs? Especially the ones who were kind enough to (usually wrong) estimate if the bug was easy or hard.

After a few minutes philosophizing he changed his mind to provide rough estimates to help with planning sprints and stuff so we could at least try to complete multiple items even if we were off sometimes.

It was funny that he was just oblivious to why he was coding and didn’t care about users, funders, or other teams.

This isn’t specific to Jira, but we did use Jira, but it is part of some devs just not caring about anything but what they focus on.

This guy was probably 45 and had operated for like 20 years. But I guess never in an environment that had production dependencies.

0 comments

3 comments · 1 top-level

pm905y ago· 2 in thread

You want devs to not care about anything but fixing technical problems though.

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.

prependOP5y ago

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.

merb5y ago

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.

1 more reply

j / k navigate · click thread line to collapse