With the exception of ublock devs.
This is one of those cases where if I’m saying an hour I mean and hour and will proactively reach out as soon as I realize that hour is wrong.
I get this is meant as a joke about how difficult is it to estimate things, but this isn’t on anyone but me and making sure I am communicating my progress. Anyone who has the title of senior developer and disagrees is senior in name only.
And I post this as there is literally a production issue being discussed because procrastination is always part of my estimates. The troubleshooting revealed it’s not my bug, it’s on that other team’s so I get to wait for them to fix their data and confirm my teams stuff works once the data is correct or I get to fix it live; my favorite but exceedingly rare.
The adrenaline of that is awesome and I question the career choice of anyone who dreads this stuff.
The usual paradigm for dev estimates is double the number, bump the units.
1 hour -> 2 days.
I’ll retire in 2 years
So basically 4 decades
At that level (of age), choices come into play.
I didn’t say which hour. This one isn’t looking good, though.
Haha, i’ll use that
I’ll fix it in an hour. When I get to it in a couple of weeks.
*months
An hour of CPU/brain time, not wall clock time.
Allow a 100:1 wall clock to CPU/brain rate
“And if you keep interrupting me it’ll be even longer”
Apparently I am just an LLM running on an organic substrate.
under promise over deliver. Always.
I promised a number of hours under any sane estimate and delivered four days over the estimate. Success.
This is why I avoid giving concrete estimates whenever possible.
But if your hand is forced, it should always be 2x-10x the actual estimate, depending on the complexity of the task, and never less than 2 hours.
This is one of those rare occasions where “IT” might have been better fully punctuated as “I.T.”, but the thought of using “Scotty” as a verb meaning “generously pad all estimates” amuses me.
e.g. “If I want to cover my a—, I should Scotty it.”
This right here
This is actually wisdom. I use a 4x fudge factor.
I estimate how long would it take. Then I add some buffer of 20% to it. Then I double it and call it good.
I have always told my team “remember that last piece of work? Add an appropriate fudge factor to this estimate to deal with those sort of problems”
There’s usually a last one, if not there’ll be one I can call by name
I just say “five days”
Ah, I see you’ve looked at my JIRA tickets with my new employer
An hour of ideal developer time. Too bad there’s only 3 of 4 of those per quarter.
Hey we just tell you the estimate. If it doesn’t get in the sprint that’s not our fault.
“ It’ll be fixed in 1h. 30min if you leave the room.”
For me I often have a fix in 5 minutes. I just don’t have the time to review and push
Never fix anything in 5 minutes.they will expect you to fix every other problem in the same time.
The “in an hour” is relative
