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
Hey we just tell you the estimate. If it doesn’t get in the sprint that’s not our fault.
An hour of ideal developer time. Too bad there’s only 3 of 4 of those per quarter.
“ 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
