Hacker News Reader

> My workaround was to coach non-technical managers to pick up clues from the person's peers. If you privately ask 3 random team members to estimate tasks and 1 person constantly gives estimates 10x longer than anyone else, that person should be watched closely for performance issues.

So I had a boss who would call a group meeting, bring up a problem that needs to be solved, and ask people who can do it. One engineer would explain that this is a research-level AI problem that would take years to solve, another engineer would say he's going to have some time to hack on it later in the week, and a third would say that he can pull an all-nighter tonight and solve it. So the manager would pat himself on the back for a job well done. He created a spirit of healthy competition in the team, he exposed the slacker (the first engineer) for what he is, and he squeezed the third engineer for all he got. A year later, the team would be back in the same place, with the manager calling a meeting and bringing up the same problem, which as it turns out the users are still suffering from and higher-ups in management are pestering him about again.

> A year later, the team would be back in the same place, with the manager calling a meeting and bringing up the same problem, which as it turns out the users are still suffering from

I thought the third engineer pulled an all-nighter to solve it?

Cause the all night hero did not actually solved the issue, just made it less visible for release checklist purpose. Which is not the same as fixing it for users who kept complaining.

I am guessing that the first engineer was right. Usually there is not one solution to the problem and judging who's the slacker by estimates might be wrong. You can usually hack something up quick, but making a strong and lasting solution requires more time.

Judging who the slacker is by estimates is wrong, period.

There's a habit of technical folks to come to conclusions they shouldn't, and this is a perfect example. It generally manifests itself in interviews where the technical interviewer will come to conclusions that don't necessarily follow, only in this case it's not in an interview, but with respect to fellow co-workers.

I mean, you can see the hubris in the poster, who would have you believe that they're somehow "training" their management to "spot poor co-workers". Yeah, ok.... sure you are. Because managers are like monkeys apparently?

So the manager exposed the slacker (the first engineer) for what he is, and he squeezed the third engineer for all he got.

That's some dark humor, there.

But in terms of "exposing" how many managers in the industry think -- so true, so very true.

I constantly give estimates that are about 1/2 ~ 1/5 of the actual because I am overly optimistic (and the thing about unknown unknowns). I have done this for 20 years, so you'd think that I would get over it, but apparently I am a dumb-ass.

But apparently, this is in the opposite direction of what you are talking about. That said! If I were to pad my guesstimates, then it could legitimately look like sand-bagging. I don't know that there are any easy answers. I am trying to become more accurate (if for no other reason than not having to work over Christmas holidays to keep up with my promises), but estimation is hard!

10x is excessive, but I'd also watch closely the relationship between estimates and actual time taken. My estimates are probably 2-3x longer than they where when I first started out because I realized that I was consistently underestimating tasks. Despite being warned about it consistently in college, I still find that virtually everyone, when asked to estimate a task, gives an estimate based on the best case scenario where they encounter absolutely no issues while executing the task.

The golden rule of estimating: double it and add 20%. The sooner you start doing that, the sooner you start underpromising and overdelivering instead of the other way around.

Why add 20%? That's upside precision for something so inaccurate. 2.2x is a good way to set a budget for someone doing a task after it's already been done once by someone else.

The golden rule of estimating is to measure past estimates and use them as a multiplier in future.

The platinum rule is to stop estimating because it's useless.

Right. Estimating before you even know what you _don't_ know is tea leaf reading. It's better to ask the person who wants it done "how much is this worth to you", or "what's my budget to get this done", and then work from there.

Double it, then add 20% make a 2.4 modifier.

  20*2*1.2 = 48  
  20*2.2 = 44 // I, also, was confused myself at this point  
  2 *1.2 = 2.4 // not 2.2

Starting out I was told double it and move up a unit.

2hrs === 4 days.

A week == 2mths.

Anything past that would never get done.

He was a cynical bastard but not a bad guy and sadly he was in a lot of dysfunctional environments not that far of the mark.

The golden rule of estimation is to give a 1-10 confidence level and if your confidence level is below a threshold (7-8 for example) then also define the risks. Finally, use that analysis to give a reasonable upper and lower bound (or be honest and say "I don't know).

I remember reading a research (don't have a link, sorry) that when one employee gave a one-week estimate and another employee gave a two-weeks estimate for the same task, and each of them delivered the output in two weeks, most managers perceived the first employee as more competent. Which, if true, would explain why most software projects are underestimated -- people instinctively perceive this, and want to be seen as competent.

An interesting experience is to estimate things in your own life. You plan to do something, write down when you expect yourself to finish it. It is quite humiliating to notice the effort you put into convincing yourself that you are more productive than you actually are. Unlike with job, you can't make the excuse that impressing other people is a good strategy. Yet, it can take a lot of work to stop doing that.

Also, not all engineers who mislead their progress are doing so out of malice or laziness. Sometimes they have too much work and don't want to be the person complaining about the work load, especially if they think everyone else is managing fine.

If a manage doesn't pick up on it early enough, then shit will eventually hit the fan.

I’ve worked in an environment like this. How did you discover the second full-time job in the end?