- cross-posted to:
- programmerhumor@lemmy.ml
- cross-posted to:
- programmerhumor@lemmy.ml
You must log in or register to comment.
I’ll fix it in an hour. When I get to it in a couple of weeks.
Put it in the backlog and we’ll prioritise it in the next sprint planning. Except we’ve already got a good idea of what’s going in to the next sprint, so we’ll probably get to it in a month. Or two. End of the year tops. Bring it up in the quarterly planning if we haven’t finished it yet, and maybe we can squeeze it in before Q2. Unless the win the ACME project in which case all hands will be on that, so actually plan for it to be in production by Xmas. No, the one after that.
*months
I didn’t say which hour. This one isn’t looking good, though.
Haha, i’ll use that
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.
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.
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.
under promise over deliver. Always.
I promised a number of hours under any sane estimate and delivered four days over the estimate. Success.
“ It’ll be fixed in 1h. 30min if you leave the room.”
With the exception of ublock devs.
Hey we just tell you the estimate. If it doesn’t get in the sprint that’s not our fault.
For me I often have a fix in 5 minutes. I just don’t have the time to review and push
The fix might be 5 mins. Figuring out wtf was wrong in the first place is the time consuming bit. Especially if the report doesn’t contain a repeatable process to trigger the error condition.
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
