there was a famous psych test from the early 90s when some social scientists were studying the new breeds of coders. They did a few of them including one where a programming task of ordinary complexity was assigned.. the programmer was asked for an estimate of the time to solve it, then they solved it. IIR a preponderance of results were an estimate of "30 minutes or so" and then the actual wall clock time to a solution was closer to two hours.. many times.
Analysis was that the engrossing and engaging activity of coding directly warped the time-sense of the coder, as a regular phenomenon.
As an aside another test at that time was comparing the production results of someone using a mouse-driven interface versus someone using a keyboard only. The keyboard-only users repeatedly claimed to be faster than any mouse-user, but the timed tests were the opposite, by a large margin.
Really interesting. I always put bad estimates down to individual biases, not something more systematic. I’d be really curious to see if this also is true for bigger tasks and whether it changed over time (at least for me I can honestly say it didn’t), small insights like there might reduce friction when working within a team or with narrow deadlines
As a child, I quickly learned to multiply any of my father’s task time estimates by at least 3.
Unfortunately he had anger issues at the time, so it was a constant cycle of “do this thing, your taking too long, I’m adult throwing a rage tantrum at kids, repeat”.
Analysis was that the engrossing and engaging activity of coding directly warped the time-sense of the coder, as a regular phenomenon.
As an aside another test at that time was comparing the production results of someone using a mouse-driven interface versus someone using a keyboard only. The keyboard-only users repeatedly claimed to be faster than any mouse-user, but the timed tests were the opposite, by a large margin.