[gjsman-1000]

Perhaps; but this is a developer's own output with an AI tool, compared against their own historical output when they didn't use it. Apparently, the average developer (read: quite possibly most people here) can't even hit the broadside of a barn in estimating their own productivity.

[dragonwriter]

That this is generally a problem, and was established as such before software development existed (the big thing people usually point to is a RAND corp from the 1940s) and is the whole motivation for Wideband Delphi estimation methods invented shortly afterwards (of which agile "planning poker" is simply a particular more recent realization) for forward estimation, and why lean methods center on using a plan-do-check-act cycle for process improvements rather than seat of the pants and subjective feel.

But despite the popularity of some of this (planning poker, particularly; PDCA for process improvements is sadly less popular) as ritual, those elements have become part of a cargo cult where almost no one remembers why we do it.

[freedomben]

But this is still regarding forward estimating of future work, whereas GP is talking about gauging actual, past work done. The problems with forward estimation are indeed widely known, but I doubt most people realize that they are so bad at even knowing how productive they were.

[sureglymop]

That doesn't surprise me at all. Isn't software engineering in essence about being constantly confronted with new problems to solve and having to come up with a sufficient one on the fly? It seems very hard to estimate this, even if you know yourself well.

[lupire]

They were 20% underestimating how long it took them to do a 1-8 hr task that they had just completed.

It's like Tog's study that people think Keyboard is faster than the mouse even when they are faster with the mouse. Because they are measuring how they feel, not what is actually happening.

https://www.asktog.com/TOI/toi06KeyboardVMouse1.html

[marcosdumay]

That is a very weird set of findings.

This one in particular:

> It takes two seconds to decide upon which special-function key to press.

seems to indicate the study was done on people with no familiarity at all with the software they were testing.

Either way, I don't think there is any evidence out there supporting that either of keyboard-only or mouse-only is faster or equivalent to keyboard+mouse for well known GUIs.

[Jensson]

I code with mouse to move the cursor, and I coded fast enough to compete with the fastest in the world in competitive coding. So I don't think keyboard is significantly faster, if it were I wouldn't have been able to write solutions as fast as the fastest in the world did.

But I think its fair to say that its much easier to learn to use a mouse effectively than keyboard navigation, so most people are probably faster with a mouse.

I did try to use keyboard only editors, spend a lot of time on that, but I was always much faster with mouse cursor to navigate and rearrange or copy parts of the code.