ProgrammerHumor
believeThem
Discussion
Said it'd take an hour, not an hour from now
An hour from when I decide to start working on it.
Well, an hour after I start working on it, and I've got the particular code loaded up, and after lunch for sure, and if there are no new personal emails...
Personal email? You mean team meeting? Which follow by another meeting. And after that…
Too real. "You said this task would take 15 hours, it's been one week, how come it's not done yet, any roadblocks?" "You might want to take a look at my calendar and see how many hours are left after subtracting all the meetings... I'll update you on the status again at next week's meeting".
I know this is mostly tongue and cheek but realistically you should be building your other obligations into your estimates...
When someone asks you when you can hang out, you don't say in an hour knowing you are not even gone, you need to shower and eat first, etc.
Your calendar is right there. Especially for recurring team meetings. Consult it.
I try but it can be unpredictable, especially if the company owner is involved. A ton of adhoc meetings of he is.
I usually estimate like -the project will take approximately x hours of uninterrupted time. However a b c is on my list to do, as well as y amount of meetings. So I estimate it will be done in about (a + b + c + y + x )*1.5 hours.
Yes all this or eng just don’t give a shit because they can just avoid doing actual work and get paid 150k
That's a new one. Out of the product owner, the BSA, the scrum master, the project manager, the architects, the team lead and the engineers, the engineers are the only ones who actually build anything, but they're the ones who are only there to collect a salary.
Quite the hot take you've got there.
I suspect you found the PM or scrum master, lol.
I've had jobs where this worked, but I had one job with an office culture of "don't ask me a question in teams, add a 15 minute meeting on the calendar and we'll talk about it then" which essentially meant at the start of my day I might have 30 minutes of meetings on the calendar, and at the end of the day, looking back, I had 5 hours of meetings from people asking me questions.
My boss told us to limit our meetings to 2 hours per day. 1 of those hours is always going to be stand-up, sprint planning, or retro. That leaves one hour. Laughable.
I’m sorry, how often are you having retros and sprint planning, and how long are your stand ups??
My current SM set up a 1-hour call from 10am-11am every weekday except Friday. It's a multi-purpose call, but usually it's just for stand-ups. Whatever is highest priority is what we do (and retro is rarely high priority for our business partners).
"You want me to go to a work meeting? The thing that killed Julius Caesar??"
and who starts a task at 1:32.
I'm never telling someone I'll have something done in an hour unless it's already done. Never know with software.
very well said
I once told a pm that a certain issue would take 5 minutes to fix and it would be done in a month. I got other tickets and priorities from above demanded that those came first.
“Yeah, we can do that”. Next day: “is it done?” Meanwhile, there is a change management process that we are all aware of and you already now what I’m working on.
Am hour after they finish the other 10 on the spot requests you asked lol
Real
Hold up.
We gon' rock it 'til the wheels fall off
Wait a minute
Something ain't right
Lessons had to learn: Always report your estimates in scale: minutes, hours, days, weeks. No numbers - just scale
As a rule, I don't give anything eta of less than a work day. Things can easily escalate, and also I might have other stuff to do. The most I might give is "this should be pretty quick, I'll have it by eod"
Developers with these types of communication skills excel.
I don't know why so many developers are such people pleasers who over commit to work. As someone who manages a team if developers, I don't want to hear a nice estimate and then have it take five times longer. Be conservative and don't give me an exact estimate unless you are confident in it. Don't give me an estimate without first baking in your other priorities and meetings. When I ask "do you have an estimate", just say, "no, I need more time but when I am closer I can provide a more accurate estimate".
Don't give me an estimate without first baking in your other priorities and meetings.
This is the main problem for me. If I work in an "drop everything now work on critical issue" environment, there may never be an opportunity to even work on it, because stakeholders would've deprioritized for the new shiny thing.
Yeah I would not recommend working in an environment that operates that way!
The only things you should be dropping your work for are major impacting production bugs or outages.
Sprints are 2-3 weeks long. If whatever you were working on this sprint was a priority when the sprint started it shouldn't suddenly be deprioritized the next day. If something new comes in and they decide they want it more than what you are working on, then you can certainly switch to it next sprint instead of continuing with your current project, but dropping everything already in progress usually doesn't make sense.
If this was a recurring problem I'd be job hunting for a company that has a better vision.
I'm telling them how long it will take, not when I'm starting it
Or the interruptions during that hour...
Yea I'm learning a new framework to fix the bug. Is it needed to fix it? No but I would prefer it
[removed]
What? You quantify the number of debugs? How does that even work?
A unit of debug is when you add print("Here!") and rerun.
Fixing the bug will take no more than an hour. Getting through the release process? You're looking at weeks there.
oh yeah to fix the code for production? 15 minutes. To deploy to production? 6 hours because of enterprise environment. Yes production was down the entire time.
I have a board I must go to first to begin work on a PR, and then do approve release once its done. They meet only once a week. There must also be a peer review that itself takes at least a week to set up.
They call this "agile".
This, user thought git is big fucking trunk instead having branches
They did fix that bug in an hour, it just turned out that the bug was suppressing a bunch of other bugs.
Ah, the bug that was actually a workaround, classic.
Every time I’m asked to give an estimate, I give 2. How long I think it’ll actually take, and the original estimate + “with distractions.” As soon as the motivation comes to start the task, I’m immediately derailed by dumb ass messages 🫠 Takes forever to get shit done
Seriously! It will be ready an hour from now and I'll tell you if that changes. You don't need to keep asking if that's still true.
What about the cover sheet for the TPS report? Do I send another memo?
The fix took an hour. But then I need to make a PR and wait for that to be reviewed. Then wait for the build. Then wait for the deploy.
1 business hour, obviously
Honestly, since this is something I struggle with, real question; how do you "explain" the gap that exists between "fixing an issue in an hour" and actually starting to the powers that constantly scrutinize you?
I've always struggled with flat out saying "yea didn't feel it today bruh and it just took a long time to get into it today"
[deleted]
Maybe, I should have used any presentation template.
What do you think is the best template for this one?
It seems it didn't affect the meme though.
I mean 4 hours is a reasonable time to fix the bug
There, I changed the typo in the text.
Now I have to commit/rebase, check for the pipeline, update the task on JIRA, send X mails to everybody telling that the bug is solved, report that false phishing mail I just received, wait for QA to validate, update the documentation (task, feature, deployment instructions,...), do my timelog, do the timelog of me doing my timelog,...
Aaaaand release failed
Impressive that you went through 4 hours without having a few mandatory meetings.
What mandato- oh these ones! Yeah I've worked long enough in IT to go into auto-pilot and continue working.
So include all this in your estimate.
If a contractor is building a fence in your yard, and they say it will take a day, you expect them done and out of your yard in a day. You don't expect the estimate to just be for digging the holes. You don't care what the process is. You don't care if their work is only to dig holes and they subcontracted out work for installing the fence to someone else. You just want to know when I will be done so you can know whether you can let the dog out or if you need to plan a dog walk again tomorrow.
But is there anything blocking you? Do you need help? How come putting the poles in takes longer than taking the fencing out? Please inform me when you've put half the poles in.
Also you think it would help if you did some pair-fencing? 2 people much better at putting in poles.
These are all great questions to ask.
These questions can be really frustrating but if you build up your relationships with these people they will learn to trust your process.
If these questions are seriously triggering for you I would suggest some self reflection. These questions are just meant to help you and the business get the job done efficiently. Don't take them as some sort of attack on your abilities. The PM/Scrum Master/whoever is just trying to ensure you have everything you need.
If they are interrupting you too often with these sorts of questions just kindly tell them that. "Hi, I need some dedicated focus time to work on my task. Could we please schedule calls for these check-ins so I can avoid context switching and come prepared? I was thinking we could schedule them every other day at 10:15 if that works for you? In the meantime if anything changes on my end I will reach out immediately. Thank you." Then proceed to ignore any and all other communication from them.
These are questions you ask of the junior that just got hired, not senior whose been with the team for more than 3 years. And yet here we fucking are.
Don't quote bugfixes.
It will take only an hour if I am not constantly interupted by people who think they are too posh to raise a ticket, and the chances of that happening are between zero and negative infinity.
He probably will, but then QA, DevOps, pipelines and company bureaucracy will stop the fix for between 2 days and a week.
If management didn't insist on unrealistic deadlines, this wouldn't happen. :-)
The biggest amount of time taken on a bug is about finding it
Sokka-Haiku by Firedriver666:
The biggest amount
Of time taken on a bug
Is about finding it
Remember that one time Sokka accidentally used an extra syllable in that Haiku Battle in Ba Sing Se? That was a Sokka Haiku and you just made one.
I always loved when people asked me how long it will take to fix the software.
Dude, if I knew, I would know where the bug is, and then it wouldn't take anything at all.
If there’s an issues tracker system I don’t need anyone to remind me anything. That’s why it was created in the first place. I see what I’m working on. If it takes more time to fix, then it is 🙂
Fix the bug: 1 minute Write new tests to cover the behavior: 1 hour
Well, it wasn't said when that 1 hour would start.
took an hour to pin point the issue
Takes a week to fix it without crashing everything for months :D
It doesn't mean "it will be fixed an hour from now" it just means "I'll fix it sometime today or tomorrow, and it will cost one hour"
And that last bit means "I will book one hour on it, whether it'll cost me 1 minute or 59."
But if they commit to a time and then don’t finish, I’m considered the annoying project manager for verifying that with devs 🙃
It’s all fun and games with trying to work with some devs until you realize they didn’t follow proper specs or scope, and instead of working on a patch or deployment, they inserted a little Easter Egg they made into the software.
Then I have to go back to the client to explain why Jimmy over here didn’t have that ready, but had an Easter egg no one asked instead.
A good engineer will pad their estimates to account for unknowns.
But a good PM should be doing the same. Don't tell the customers and stakeholders the engineering estimate! Abstract it or round it up.
Also sales shouldn’t be selling stuff that doesn’t exist and then promise clients the functionality in x time frame and then try to hold you to these ridiculous timelines. That seems to happen WAY more often than a bad estimate from a dev.
they inserted a little Easter Egg
I found a fucking song in the codebase. Someone wrote a full song custom-made for the products we sell and put it in the codebase (about 10 years ago before ChatGPT and all the nonsense).
It will take an hour.
Next sprint...
Yes remind them every 1 hour, cause that's what they said.
bug off
1 hour coding <> 1 hour "calendar time"...
...well, unless you actually let the coder code, but we all know that ain't happening.
Is your job title really just "coder"?
All that other stuff is part of being an engineer. You need to include that in your estimates.
A contractor at your house doesn't estimate the work to replace your roof as just the time to lay the new tile. They include ordering the tile, pulling up the old, laying the new, a lunch break, etc.
And how exactly do you expect people to estimate things that are unknowable?
Also, an IT person hired at your IT department is not an independant contractor. He's your coworker. He's estimating his work, not whatever random speedbumps you feel fit to throw at him on the way.
If you want an independant contractor then hire an independant contractor and pay the price (because, yes they will make room in their estimates for any BS you can come up with, and they will happily pass the cost onto you).
And how exactly do you expect people to estimate things that are unknowable?
With experience and being conservative. You might not know how to fix THIS bug but if you fixed thousands like it before you should have a good idea what it might take. Is it a bug in a code base you work on every day? Great, maybe a day or two. Is it a bug in legacy projects you never worked with? Great, at best give it weeks. Want to look at it for a few hours before giving an estimate? Say that.
All of the scrum process meetings are part of an engineer's work. They are typically recurring schedules. They should be included in estimates. If you know you get interrupted often, include some more buffer in your estimate. If you are in the middle of something you can't put down, include that in your estimate. Include the time it will take to PR, merge, build, test, write release notes, get approved, and deploy. No one asking for an estimate cares how long it will take to fix it on your machine.
Getting better at estimates is like getting better at coding. It takes time but it is something you should keep working on. As a rule of thumb, it's always better to say it will take longer and be early than to say it will take shorter and be late.
That might work if you follow a waterfall workflow in a highly rigid organization that never change workflows.
Reality is that your task today will likely not be your task tomorrow, so estimating tasks into next month is pointless and a waste of time and resources.
I've spent decades working under scrum. I have absolutely never encountered the pattern you are describing regarding tasks changing day to day... If that is your experience it sounds like your organization is incredibly unorganized and is operating in a very reactive manner.
Under scrum, how could you even start something new tomorrow if it wasn't in your sprint today? You would need to swap out story points to bring it in. And that should only be done for incredibly high importance issues like major production bugs and outages. If you are experiencing issues like that often, you have a serious quality problem.
In terms of projecting estimates months in advance, yeah I agree that is pretty pointless. I don't think I suggested anything of the sort?
Reality seems to be, one uninterrupted hour, or a full normal day.
An hour of solid work, so when you factor in all the interruptions and administrative work around it... Two weeks.
I experience more like "with proper assessment of the requirements and review it takes 2 days" "no, it has to be done today! The customer is angry already because we promised it would be done yesterday without consulting you until now" (next day) "The changes work, but there are 2 new bugs. why?"
People don't know that our time is different.
To understand IT time follow this rule
IT Time = human time * 2 * elevated at the next time measure.
lets take OP example
IT time = 2 hours * 2 * (what's next to hours? DAYS)
so we have
IT time for 2 human hours = 4 days.
another example
"I'll fix it in 4 days"
IT time = 4 days * 2 * months
IT time for 4 days = 8 months
most likely USER ERROR.
11 year old nodeJS backend with no test in a homebrewed framework? Yeah.. It will take between 1 minute and 3 months.
Every 2 days*
This one made me chuckle :-)
No need to . Everything will be handled in programmers time .
Sprint start: Quick story, 1 point - 3 at worst
Sprint end: My patience and sanity are at the breaking point
Fixing bugs just take 1 min which technically 2 days
I will fix it in 5 minutes after I watch this obscure 8 hour youtube video about the lore of a game I've never played. Jeez guys
Sometimes take me 2-3 days to find bug, which takes 2-3 mins to solve sometimes, it blows me off😂
If I say I use 2 days on a task then I use 3 days but if I say I use 4 days on the same task then I use 4 days. What is important, exact estimates or speed?
This is why I never speak in absolutes when talking about how long something will take or how confident I am a fix will work. "It shouldn't take me more than an hour" or "This typically fixes this issue". That way it's easy to follow up with something like "It turned out more complicated than I was expecting" or "Something more pressing came up and your ticket got delayed, apologies"
So my old company, we had a term for this. Boss would ask me about when my team expected to have a "planned breakthrough". He had to tell his boss something, after all.
Lmao maybe i suck ass, but when i say it takes an hour it usually takes 30mins or 4h+
Nothing in between
It makes you wonder if programmers actually know what they’re doing /s
It's just one hour, without interruptions.
dont let a bug hear you say "this should be a simple fix". thats gonna cost you an entire day
Usually my problem is that I’m working 20 at once, priorities.
In my experience, if I say an hour that's mostly waiting for the CI to run. I used to have endless meetings where I'd fix a bug the PM assigned before we would leave the meeting.
Knock knock… ‘Is it done?’ – Manager every 5 mins
I dont remember, but I dont think I've said I'll jump into it immediately, though I might have... who knows.
Haha, so true. Nothing makes that 1-hour fix turn into 5 like being pinged every 10 minutes 😅
1 hour is not a good estimate. Everything takes, at least, 2 days unless is urgent enough to override other priorities.
And each message asking how it's going is an extra hour of work. Not out of spite but because you made me lose focus.
Why is it so hard for programmers to estimate how long they need to finish a project. 2 months ago someone said 15 working days, now they need another month or two. I don’t get it. As a programmer who is able to accurately estimate timelines, it frustrates me.
Most bugs only take me a few minutes to fix, after a few hours or days to figure it out
This is extremely true. Hours with a debugger to figure out exactly what is happening. One line change to fix it.
How long do the other bugs that you created take to fix after?
this is why i hate rubik's cubes. You fix one thing, and it changes 5 other things
If it's something you're interested in learning it's not as difficult as it seems, you're probably solving it wrong because there's a few specific algorithms you can use to solve section by section. We all learned in an afternoon from the "solve a Rubik's cube in 10 mins" video. It definitely took longer than 10 mins but we all eventually got it.
But... that would take all the frustration out of solving it.
Except that the frustration comes back in the shape of wanting to become faster or wanting to solve some other more complex twisty puzzles.
Kind of? But wouldn't solving any puzzle do that?
hehe thanks, i actually had this conversation with a colleague who knows cubing algorithms.
Fiddling around with it with no prior knowledge seems more enjoyable to me. Looking up the algorithms feels like looking up hints or spoilers to a puzzle.
I'll stay blind for now. :D
You might enjoy figuring out other 3D puzzles and collecting them as opposed to getting as fast as possible. Those are the two sides of cubing.
yeah like the wood/rope/ball/metal puzzles where you have to unclutter or assemble something? I do have a few of those :)
Speed wise, I'm more into speed sudokuing, but honestly the whole speed thing is a bit too repetitive.
Fair. I tried myself for a week myself. Now that I can do the algorithms with one hand and blind (only need to look after it's done to see which one is next) it's a fantastic fidget toy.
Hopefully, all the automated tests would catch them.
The one that the junior software developer / intern vibe coded with AI using deep seat that he's not supposed to be using but didn't tell anyone?
I assume this is a joke based on the common joke that fixing bugs creates others, but in reality, that usually doesn't happen for something as small as a one line change. And if your project has good unit tests and integration tests, you will catch them before you merge with main.
Seriously!! I feel like i fix a hole in a dam with a chewing gum, and then the whole dam falls apart and i run for my life. debugging ptsd!
Whenever I explain a fix I have to describe what we thought the problem was, what the problem actually was, how we are going to fix it and how we are going to test everything else to make sure the fix didn't break something else.
"By running the unit test cases and integration test cases"
good one
And a few hundred lines of tests to ensure it never happens again
Immediately followed by a hard face palm and emotional disappointment that I didn’t see the obvious fault
Then followed by finding out that functionality you fixed is actually no longer used.
I personally do silent screaming and fist pounding on the bed (wfh)
It is always, "Why wasn't I more observant writing the code, just control what you write, you dumb bitch, use your eyes". Just to end up in the same situation the next time.
This exactly! Existential dread incoming :D
Typing the bug up on devops, creating task cards and steps to reproduce often takes up 90% of the time too. Then it still has to be code reviewed, tested, sometimes update screenshots in customer documentation, plan a release branch for Sunday which is oir maintenance window. That's a week gone.
In the old days when building the company, we just got the bug report, 2 min change and I'd upload it to live, there and then.
Building a company from scratch now with the full.process we do now wouldn't have worked, nothing would get done. Much as having something formal is necessary now due to how complex our monolithic system is, I do long for the old days where all we did was make things, break things and fix things.
Yup. And when I know enough to give a realistic estimate, I'm most of the way there already.
Took me 3 hours to figure out I needed to change one line.
Me last week: Three days debugging a focus issue. Single line deleted to fix it once the problem was located
“There is an old story of a boilermaker who was hired to fix a huge steamship boiler system that was not working well.
After listening to the engineer’s description of the problems and asking a few questions, he went to the boiler room. He looked at the maze of twisting pipes, listened to the thump of the boiler and the hiss of the escaping steam for a few minutes, and felt some pipes with his hands. Then he hummed softly to himself, reached into his overalls and took out a small hammer, and tapped a bright red valve one time. Immediately, the entire system began working perfectly, and the boilermaker went home.
When the steamship owner received a bill for one thousand dollars, he became outraged and complained that the boilermaker had only been in the engine room for fifteen minutes and requested an itemized bill. So the boilermaker sent him a bill that reads as follows:
For tapping the valve: $.50 For knowing where to tap: $999.50
TOTAL: $1,000.00”
You were just trying to find the right place to tap.
Why don’t you just use AI /s
most bugs take seconds to fix, i usually just dislike the person asking
As someone who has to fuck around with mechanical logic, analog systems, and automation systems, diagnosing the issue is often very easy and quick. But figuring out a solution to it is not. And with mechanical/analog system we can't just write a piece of code have a quick try even if you got PLCs.
Lot of the time you can actually break something physically if you fuck up.
Along with this parts take day or two or a week to arrive, and if you need to machine something... Well... Better tell boss shit ain't happening quick.
If there is a piece of software running on a computer tied to it all (Often like Labview or such) then just fuck it... It's a whole thing.
Or a few hours or days to psyche yourself up
THIS
Exactly. They shouldn't stress us out, we are already busy trying to find that little line of code that's ruining all of our work.
That's what I currently struggle with... I'm a c# (self-taught) dev, but for some reason I'm now working in React for a global client of ours, being the only dev on this project and managing 60+ markets...
I do enjoy learning and it's fun to become more of a "real" dev, but damn do I hate how u structured React is compared to C#.
When I'm asked for time estimates I need to honestly separate the tasks in debugging and actually solving, because I'm fairly competent at solving the bugs we do have, but it will take me some time to figure out how this entire site is built (I took over from a consultant team of devs that I have been leading for the last year so I have some knowledge of the architecture behind but I didn't really dove too deep in the functions due to then being more competent in React than me, I reviewed the logic to make sense but other than that they had fairly free range)
Sometimes, you've figured it out, but other environmental factors can prevent you from making it available.
I recently finished a task where I've informally titled the retrospective write-up "Why it Took u/chaosTechnician 90 Hours to Write Five Lines of Code." I knew what needed to change and how to change it, but the process to make the change correctly was apparently broken. And so was the process for actually packaging the patched deliverable for the client. And so was my local dev environment for of the platforms I needed to confirm on since I had been told by my supervisor that I wouldn't need to build for that platform. And so on.
It was ridiculous.
I tell my clients "It took me 3 days and 5 minutes to fix"
And then 17 messages back and forth to get it through the PR.
I spent like 90 minutes trying to fix a bug yesterday before realizing I just needed to add one line 😫
Only 90 minutes?? Boring ahh bug 🥱🥱
Yeah, one year ago me would have taken 8 hours 🤣