We stopped roadmap work for a week and fixed bugs • Hacker News Board

Re: We stopped roadmap work for a week and fixed bugs

#151

Post by demaga » Mon, Nov 24, 2025, 11:04 AM UTC

etamponi wrote: post #145

Ex-Meta employee here. I worked at reality labs, perhaps in other orgs the situation is different. At Meta we did "fix-it weeks", more or less every quarter. At the beginning I was thrilled: leadership that actually cares about fixing bugs! Then reality hit: it's the worst possible decision for code and software quality. Basically this turned into: you are allowed to land all the possible crap you want. Then you have…

From the post:

> That’s not to say we don’t fix important bugs during regular work; we absolutely do. But fixits recognize that there should be a place for handling the “this is slightly annoying but never quite urgent enough” class of problems.

So in their case, fixit week is mostly about smaller bugs, quality of life improvements and developer experience.

Re: We stopped roadmap work for a week and fixed bugs

#152

Post by pjc50 » Mon, Nov 24, 2025, 11:05 AM UTC

ChrisMarshallNY wrote: post #139

pjc50 wrote: post #129

Earlier quoted context omitted.

I think the worst case I encountered was something like two years from first customer report to even fully confirming the bug, followed by about a month of increasingly detailed investigations, a robot, and an osciliscope. The initial description? "Touchscreen sometimes misses button presses".

Thanks. I love hearing stories like this.

I'm no Raymond Chen, but sometimes I wish I'd kept notes on interesting bugs that I could take with me when I moved jobs. I've often been the go-to guy for weird shit that is happening that nobody else understands and requires cross-disciplinary insight.

Other favourites include "Microsoft Structured Exception Handling sometimes doesn't catch segfaults", and "any two of these network devices work together but all three combined freak out".

Re: We stopped roadmap work for a week and fixed bugs

#153

Post by dsego » Mon, Nov 24, 2025, 11:06 AM UTC

pmontra wrote: post #118

About stopping and fixing problems, did anybody have had this kind of experience? 1. Working on Feature A, stopped by management or by the customer because we need Feature B as soon as possible. 2. Working on Feature B, stopped because there is Emergency C in production due to something that you warned the customer about months ago but there was no time to stop, analyze and fix. 3. Deployed a workaround and created i…

Yes, usually not worth it to spend too much time on proper engineering if the company is still trying to find a product-market fit and you will be working on something else or deleting the code in a few months.

Re: We stopped roadmap work for a week and fixed bugs

#154

Post by 1718627440 » Mon, Nov 24, 2025, 11:07 AM UTC

nananana9 wrote: post #144

zelphirkalt wrote: post #112

Earlier quoted context omitted.

There should be better regulation of course, but I want to point out, that the comparison with other industries doesn't quite work, because these days software is often given away at no financial cost. Often it costs ones data. But once that data is released into their data flows, you can never unrelease it. It has already been processed in LLM training or used somehow to target you with ads or whatever other purpose…

"Free" software resulting in your data being sold is the software working as intended, it's orthogonal to the question of software robustness. Software isn't uniquely high stakes relative to other industries. Sure, if there's a data breach your data can't be un-leaked, but you can't be un-killed when a building collapses over your head or your car fails on the highway. The comparison with other industries works just…

"Free Software" means something, please consider using the terms gratis software or freeware/shareware instead.

Re: We stopped roadmap work for a week and fixed bugs

#155

Post by mobeigi » Mon, Nov 24, 2025, 11:08 AM UTC

ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

I believe the idea is to pick small items that you'd likely be able to solve quickly. You don't know for sure but you can usually take a good guess at which tasks are quick.

Re: We stopped roadmap work for a week and fixed bugs

#156

Post by mobeigi » Mon, Nov 24, 2025, 11:10 AM UTC

BurningFrog wrote: post #14

This is weird to me... The way I learned the trade, and usually worked, is that bug fixing always comes first! You don't work on new features until the old ones work as they should. This worked well for the teams I was on. Having a (AFAYK) bug free code base is incredibly useful!!

Any modern system with a sizeable userbase has thousands of bugs. Not all bugs are severe, some might be inconveniences at best affecting only a small % of customers. You have to usually balance feature work and bug fixes and leadership almost always favours new features if the bugs aren't critical to address.

Re: We stopped roadmap work for a week and fixed bugs

#157

Post by zelphirkalt » Mon, Nov 24, 2025, 11:13 AM UTC

sb8244 wrote: post #6

xnx wrote: post #5

I've never understood why bugs get treated differently from new features. If there was a bug, the old feature was never completed. The time cost and benefits should be considered equally.

If the bug affects 1 customer and the feature affects the rest, is the old feature complete? It's not binary.

Yet engineers are pushed to give unknowable estimates of points and when things take "longer" (did you notice that shift right there?) they are either overdue, taking too long, or they don't, and to say: "It takes as long as it takes." is not accepted by middle management.

Re: We stopped roadmap work for a week and fixed bugs

#158

Post by khannn » Mon, Nov 24, 2025, 11:19 AM UTC

ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

I had a job that required estimation on bug tickets. It's honestly amazing how they didn't realize that I'd take my actual estimate, then multiply it by 4, then use the extra time to work on my other bug tickets that the 4x multiplier wasn't good enough for.

Re: We stopped roadmap work for a week and fixed bugs

#159

Post by philipallstar » Mon, Nov 24, 2025, 11:20 AM UTC

klabetron wrote: post #132

I introduced this to my old company years ago and called it Big Block of Cheese Day after the West Wing episode [1]. We mostly focused on very minor bugs that affected a tiny bit of our user base in edgey edge cases but littered our error logs. (This was years ago at a, back then, relatively immature tech company.) It had the same spirit as a hackathon. [1] https://westwing.fandom.com/wiki/Big_Block_of_Cheese_Day

When the world learned the wrong reason for why the Mercator Projection was adopted.

Re: We stopped roadmap work for a week and fixed bugs

#160

Post by mewpmewp2 » Mon, Nov 24, 2025, 11:30 AM UTC

khannn wrote: post #158

ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

I had a job that required estimation on bug tickets. It's honestly amazing how they didn't realize that I'd take my actual estimate, then multiply it by 4, then use the extra time to work on my other bug tickets that the 4x multiplier wasn't good enough for.

That's just you hedging, they don't really need to know that. As long as if you are hedging accurately in the big picture, that's all that matters. They need estimates to be able to make decisions on what should be done and what not.

You could tell them that 25% chance it's going to take 2 hours or less, 50% chance it's going to take 4 hours or less, 75% chance it's going to take 8 hours or less, 99% it's going to take 16 hours or less, to be accurate, but communication wise you'll win out if you just call items like those 10 hours or similar intuitively. Intuitively you feel that 10 hours seems safe with those probabilities (which are intuitive experience based too). So you probably would say 10 hours, unless something really unexpected (the 1%) happens.

Btw in reality with above probabilities the actual average would be 5h - 6h with 1% tasks potentially failing, but even your intuitive probability estimations could be off so you likely want to say 10h.

But anyhow that's why story points are mostly used as well, because if you say hours they will naturally think it's more fixed estimation. Hours would be fine if everyone understood naturally that it implies a certain statistical average of time + reasonable buffer it would take over a large amount of similar tasks.