Hacker News Reader

Comment by pottertheotter | Hacker News Reader

I think a lot of people hate giving an estimate because they have learned from experience that, even if someone tells them they won't hold them to the number, it still happens. You might be the exception, but it seems to happen quite regularly.

View on HN

Here’s my experience with that:

April estimates 5 hours of work but spends 12 on it. She justifies her overage by communicating with the PM and letting them know ahead of time the task is worse off than they thought. But to do it right she will need to go over, by roughly 5 more hours. Song the way she is taking notes of what she’s doing and then screenshots and justifications at the end to explain the work.

Bob estimates 5 hours and takes 12. He doesn’t communicate, the work isn’t finished to spec or even partially to spec, he can’t justify his time and argues that roadblocks kept him from finishing.

The latter is the person I regularly deal with and I only know one “April”.

My old man spent 30 years working as a mechanical engineer for General Electric in their gas turbine division and used to bring home these sorts of tales similar this with people who reported to him, which subsequently informed him on how he needed to communicate to the manager he reported to on when to expect deliverables.

Most memorable from this was watching his reaction while he and I were watching an episode of Star Trek the Next Generation where his exact problem was manifested into reality by his favorite character: https://youtu.be/8xRqXYsksFg

Nonetheless, I may or may not have employed my dad’s and Scotty’s method now that I have a team reporting up to me, each with their own strengths and weaknesses in delivery. Grooming them has been a genuine pleasure, though.

You missed one:

Kevin estimates 5 hours, his manager stares at him and says "I don't think it's really 5 hours, we can do it in 3" and forces Kevin to revise his "estimate". He finishes in 10 hours, clearly justifies the overrun, but gets a negative performance review.

I've had discussions like this in the past, where people ask me "can we do it in 3 days instead of 5?" And I've found the easiest way to sell it to them is to ask which 40% of the feature set they would like me to remove from the deliverable?

I feel like at least half the time when you give an estimate you come up against an unknown unknown. Typically some sort of edge case that requires an enormous amount of additional effort to overcome. So you end up with the 90% done on time or early but without that last 10% it does you no good and it’s really hard to get that last 10%

Off topic, but I can't stop thinking about "Your lie in April" reading your comment.

Probably the biggest thing that I've found makes estimation harder when I lack a clear idea of the goals of the project, what the different pieces are and how they interconnect, or how to start on the first step. This sort of barrier was really hard to overcome as a junior engineer because I found it hard to persuade people that "I don't know" or "I don't know what I'm doing with this" was an honest reflection of reality rather than impostor syndrome.

One trick I've found is to work in a company with respected Test Engineers. If you tell them "I could really use an introduction to the different pieces here", rather than saying that you should stop "trying to understand the universe", they are often happy to show you documents like a risk list and other diagrams useful for getting a mental model of a project. If you find TDD useful for getting started and getting into a good cadence with a project, they often have great ideas for how to make a project more testable. They are good people to have backing you up if you're pushing back on other forms of estimate nonsense.

Reply on news.ycombinator.com