Comment by pizlonator | Hacker News Reader

Comment by pizlonator | Hacker News Reader

Parent Full thread

Manager here. I ask everyone for estimates. Then I track how long shit actually takes. I find that:

- Some folks are scary precise in their estimates. I’d say this is like 10% of engineers. You ask them for an estimate, they tell you, and then it takes exactly that long every single time. In other words, I have confidence that if I ask one of those folks for an estimate, I can take that shit to the bank.

- Some folks always overestimate. This is rare. Maybe less than 10% of folks. When I find that someone overestimates, I know that I can take that shit to the bank as an upper bound, which is still useful.

- Some folks say they don’t know. That’s fine. Those folks are even rarer, so I don’t have to do anything smart for them.

- Most folks underestimate, sometimes hilariously so - they are always one day, or one week, or some other too-short amount of time, away from finishing their multi month effort. That’s fine. Once I know you underestimate, I know that I can take your estimates to the bank as a lower bound. For more than half of the underestimaters, I find that there’s some formula that works: like if Steve says he needs just one more day, he always means he needs five more days. So if suddenly Steve says he needs another week, then I know he probably needs over a month. That’s still useful to me and I’m totally fine if Steve then tells his friends (or HN) how dumb it is that I ask him for estimates. They may be dumb to him but I’ve got my napkin math that turns his BS estimate into something that I can take to the bank. (I don’t actually manage anyone named Steve but I was a Steve as an IC.)

So yeah. When I ask you for an estimate, I expect it to be wrong and then I look for patterns in your wrongness. For most people, there’s a pattern that allows me to turn something that looks like a nonsense estimate at first into something I can then plan around. That’s why developers I work with are “expected” to estimate.

>Some folks are scary precise in their estimates. I’d say this is like 10% of engineers. You ask them for an estimate, they tell you, and then it takes exactly that long every single time.

It's possible they are hiding their true skill and sitting inside their comfort zone, so they are really over-estimating based on what they can actually do, but are keeping that truth to themselves. A good reason to do this is to avoid being assigned more work for no real gain and pushing the work-life balance more towards life. This situation annoys some managers when they find out they weren't getting the maximum effort possible from someone for their compensation.

This was roughly my first thought, too. It may not be nefarious, though. In many software projects, if you know what you're doing, there's a lot of work that's useful-but-optional that can be delayed to the end stages of the project. So then you front-load all your hard requirements so that you can minimize the risk that you'll miss any of them. Once that's sorted, you can just knock your way down the rest of the to-do list until you run out of time.

This is actually how Scrum is supposed to work, and most the Scrum rituals are just a formalized process for doing that in a collective ownership setting. But at some point we forgot that and started confusing the means for the ends, and it all kind of fell apart.

I came here to say the same thing. It's either that or Parkinson's Law [0], usually expressed as: work expands so as to fill the time available for its completion. I find that for myself it is true, when I have more time, I take my foot off the pedal. When I am running late, I work harder to meet the deadline.

[0] https://en.wikipedia.org/wiki/Parkinson%27s_law

If the manager's happy with the employee's output, and the employee is happy with their task and compensation... Then how is that a problem?

Our field is based on trust. When the backend is having massive performance problems, and Steve tells you it will take a week to fix, that might make sense to you because you’ve seen hairy backend problems in the past, and he’s the one that looked into the technical details on this one. But you’d be pissed to later learn that it was a one line fix that he knew about all along, and he just took a week at home chilling out while others were waiting on him.

That kind of Steve wouldn’t fool me because I’m all about redistribution of XP. Even if Steve is the best at that task, I would assign it to not-Steve with some probability. If not-Steve was able to fix similar issues in less then a week then that I’d end up assigning fewer tasks to Steve in the future, which would affect his output and that would eventually affect his livelihood.

or in XP fashion you could assign it to Steve and non-Steve to work on it as a pair?

Then how would I know who really did the work?

And how would I know that non-Steve would mark on Steve or not?

Every field is based on trust, so I don't see why you emphasize that.

Once again, if as a manager, you are happy with your employee's output and feel that their compensation is fair; why would the knowledge that they could have done more change that? It was fair before. Why should the worker do more to earn their salary?

> Every field is based on trust, so I don't see why you emphasize that.

Most workers around the world have no "trust" from their manager on the number of hours they spend in a week.

> Once again, if as a manager, you are happy with your employee's output and feel that their compensation is fair; why would the knowledge that they could have done more change that? It was fair before. Why should the worker do more to earn their salary?

Because there is a tacit understanding between the two parties (if most cases, apparently you disagree) that the engineer is working the "standard" number of hours in a week (35+, more or less). If you tell your manager "I work one hour a day, and this bug took me three days to fix" and your manager doesn't mind, then it's all good.

But if you tell your manager "this bug took me three days to fix" I can guarantee he'll think it was a challenging problem that took 15+ hours of your time, and he would be pissed to know that everyone else was forced to wait for what was actually a quick fix.

As an engineer, I mean it kind of comes down to competition doesn’t it? If entity A is able to get something done 5x faster than entity B and just as well, wouldn’t you choose entity B in the future? Sure entity A might have been acceptable but at a certain point, who’s more likely to get a contract, a promotion, a raise, a pay cut, or laid off? This stuff matters, it’s how the world works, it’s no secret. Generally, pay cuts and layoffs are reserved for when the company is suffering but really what is happening the tolerance for slack is dropping, and productivity will absolutely play into that.

Nah. The people I’m thinking of are fucking magicians.

If they are hiding their true skill then OMFG.

Back when I was on product teams I could do this. The trick is knowing the codebase and problem space well enough that you're doing all the planning upfront in your head*, so the estimate given is basically just implementation of an already-existing plan, with few unknowns - just some padding for testing and bugfixing near the end.

Nowadays I'm on a maintenance team with products I'm not very familiar with, so when something needs fixing I have to spend time investigating it before being able to come up with that plan. I can usually still give vague estimates based on guesses of where the problem is, but nothing like I used to be able to.

* Okay maybe not all all, but enough that you have an outline of the entire solution where you can fill in the details as you go. Some details will increase the overall estimate as you get to them, others will be simpler than you thought and reduce the overall estimate - for me it tended to balance out.

This sums up my experience as well, giving mostly accurate estimates maybe comes naturally for some of us. I’ve been doing this for a long time though and I think that plays into it. It takes a lot of intuition that really just comes from experience but it does require a knack to some extent.

I didn’t think I was an outlier here but the more I read these comments the more it seems like we are.

I am 100% one of these people. Unless something really unexpected comes up, then I choose whether I'm working that morning (which is less than 50%) and will usually finish the work after a few hours, then commit it either at EOD or next morning. I am still considered an over-achiever by a vast margin.

Good for you. I don’t mind working with such people. I have zero interest in knowing how much of your 40 hours you actually spent working, only whether you did the thing you said you were going to do. An engineer that is more productive than everyone else but only works 5 hours a week still deserves to be rewarded the same way as an engineer who worked 40 hours but achieved the same result in the same calendar duration.

If you really can overachieve while working very little then all it means is that you could have achieved more in your life if you spent more time working. And that’s none of my business.

> If you really can overachieve while working very little then all it means is that you could have achieved more in your life if you spent more time working.

I mean, not really right? That's the whole thing with the totem pole systems we create. You are only rewarded for over-achieving so much. Anything above that causes problems, because we are jealous creatures. There are daggers in mens' smiles.

I have other interests in life and don't care that much about work, which is why I understand how it works in the first place. If I didn't like philosophy and speak four languages and lived around the world, then I wouldn't know that. Most engineers don't.

If my company were willing to make me a principal and comp me with a big chunk of equity, then hell yeah. But almost no one is, and until I have kids, I don't want to start my own company or put too much effort into office politics. C'est la vie, c'est la mort.

Causes problems because of jealous creatures?

Sounds like a really bad work environment. I tend to stay away from those.

Manager here. Managers know this too. As long as the estimate falls somewhere between over-estimator and under-estimator, most managers don't care.

Good managers understand slack capacity is needed.

Dude. Stop giving away our secrets. Some of us want to have a reasonable WLB!

I just don’t accept that accurate estimates are actually possible unless:

- the requirements are well written and complete

- they never change

- the duration of the project is very short

- the number of interruptions is minimal

- there are no other priorities

- it’s a simple change to an existing, well defined system

If all of the above is true then sure, it’s possible to come up with accurate estimates.

But most of the time accuracy problems are not (only) due to the inability of the engineer to estimate, but also the overall uncertainty of the requirements and productive time available.

The narrative around estimates is that the engineer is responsible for things being late, but in several places I’ve worked, it’s largely the externalities that cause estimates to be wrong.

When I was able to control these factors, my team and I were able to make good estimates most of the time. But it’s really rare to be able to control them.

There is no narrative around estimates that engineers are responsible for things being late.

Strictly speaking I don’t think any of your conditions have to be true for estimates to be accurate, though obviously all of those things help.

I’m reporting empirical results here based on my experience. Your theory doesn’t change the facts of my experience.

> There is no narrative around estimates that engineers are responsible for things being late.

This is a strange thing to say since I read the article as being exactly about how the engineer becomes responsible for things being late. Otherwise why is the engineer "pressured to work unpaid overtime to meet that estimate"

> I’m reporting empirical results here based on my experience. Your theory doesn’t change the facts of my experience.

Well, your experience is totally different from mine. I've certainly had my feet held to the fire when a project has been delivered late due to changing management requirements and inappropriate prioritisation of management meetings over deliverables. I've seen others do it, and maybe I've even been guilty of doing it myself.

But we all have different experiences. I was just sharing mine.

> I don’t think any of your conditions have to be true for estimates to be accurate

What would be most interesting to me would be your view on how estimates can remain accurate when requirements change. How can that even happen?

Of course estimates shouldn’t remain the same when requirements change. If you told me the same estimate after I changed requirements on you then this would tell me that I should probably ascribe a high error bar to any estimate you make.

But you said that "I don’t think any of your conditions have to be true for estimates to be accurate" and one of my conditions was that the requirements should be correct and shouldn't change.

And the point I was trying to make was that - in my experience - is that often requirements changes that are a huge driver for estimates going wrong.

If you're lucky, you work in an environment where a changed requirement automatically results in re-estimation at the customer's cost. But in the places I work, the requirements are often not well stated in the first place, so they are subject to interpretation, and it is very difficult to estimate reliably in such an environment.

And for whatever it's worth, that's been my experience for the whole of my long career. As engineers we're forced to quote against crappy requirements, and as management we're forced to accept crappy requirements in order to win the gig.

But all too often engineering is blamed for late delivery of something that sales shouldn't have sold in the first place.

> like if Steve says he needs just one more day, he always means he needs five more days. So if suddenly Steve says he needs another week, then I know he probably needs over a month.

That is a beyond frustrating even if you have gotten used to adjusting the time in your head. It also probably means it affects other work that Steve is doing and his sanity. (Steve thinks he'll finish Task A in a week, and has already allocated time for Task B in a week's time, but he's not even close to finishing Task A a week later, and now he has to work on both at the same time. Which is fine, we're all expected to multi-task, but if he constantly isn't prepared for this then it's not sustainable.)

In these scenarios do you talk to Steve about what is up with his estimation skills and time management?

It’s usually not person-specific but domain-specific.

Like, I’m really good at memory management but whenever I go to write a new malloc or GC I somehow convince myself that I’ll Carmack it in a weekend. And then it takes five months.

But if I write a compiler then I’m usually one of those precise estimators. If I tell you a month then it’ll be a month.

So, I don’t try to talk to the Steve as if he’s the problem. He’s not the problem. The problem he’s solving is the problem.

(Or maybe I just make that excuse for Steve because as I said, I’m a Steve.)

Right. Requirements staying constant is not a requirement for estimates to be accurate because when requirements change it’s customary to ask for a new estimate.

If your mechanic gave you a 1 month estimate to fix your flat tire, they'd deliver on time every time

The precise estimaters are doing more than fixing a tire and they are doing it in less than a month. Empirically, these people are often more than average productive.

It helps that I also know how to program. So I know that the task in question is hard and I know that the patch they submitted is the real deal.

Reply on news.ycombinator.com