Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We stopped roadmap work for a week and fixed bugs

lalitm.com

Post reply on HN
Print view View original

311–320 of 356 posts

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

#311

Post by cvoss »

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…

The article addresses your concerns directly.

> In one of our early fixits, someone picked up what looked like a straightforward bug. It should have been a few hours, maybe half a day. But it turned into a rabbit hole. Dependencies on other systems, unexpected edge cases, code that hadn’t been touched in years.

> They spent the entire fixit week on it. And then the entire week after fixit trying to finish it. What started as a bug fix turned into a mini project. The work was valuable! But they missed the whole point of a fixit. No closing bugs throughout the week. No momentum. No dopamine hits from shipping fixes. Just one long slog.

> That’s why we have the 2-day hard limit now. If something is ballooning, cut your losses. File a proper bug, move it to the backlog, pick something else. The limit isn’t about the work being worthless - it’s about keeping fixit feeling like fixit.

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

#312

Post by sudoit »

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…

My experience at Meta is that those weeks are spent not fixing bugs but working on refactors which increase your LOC and diff count. Many of the tasks engs work on are ones they themselves created months previously as "todos".

I question my life a lot when I'm reviewing code which appears to have been written incorrectly at first so that the author can land a follow up diff with the "fix"

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

#313

Post by lkbm »

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…

A big reason we did a "fix week" at my old job was to deal with all the simple, low priority issues. Sure, there were high severity bugs, but they would get prioritized during normal work, whereas fix week was to prevent death of a thousand cuts. Kinda trivial things that just accumulate and make the site look and feel janky.

Some things turn out to be surprisingly complex, but you can very often know that the simple thing is simple.

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

#314

Post by lkbm »

IgorPartola wrote: post #204
gregoriol wrote: post #175

Earlier quoted context omitted.

It must be part of the normal process. If the normal process leaves things like this to "some other time", one should start by fixing the process.

Say you are working on a banking system. You ship a login form, it is deployed, used by tons of people. Six months later you are mid-sprint on the final leg of a project that will hook your bank into the new FedNow system. There are dozens of departments working together to coordinate deploying this new setup as large amounts of money will be moved through it. You are elbows deep in the context of your part of this a…

I just checked and it's fixed now, but for a long time the "Shop Policies" section on Etsy shops had the text of first field misaligned[0]. That's the sort of thing that might get thrown into a fix week, but never actually prioritized outside of a "fix week" situation. (tbf, it also might just get noticed and fixed by an engineer randomly without prioritization.)

[0] See "Shop policies" near the bottom of https://www.etsy.com/shop/ForbiddenGlade vs last December: https://web.archive.org/web/20241215201533/https://www.etsy....

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

#315

Post by jchrisa »

jchrisa wrote: post #18

I just had a majorly fun time addressing tech debt, deleting about 15k lines-of-code from a codebase that now has ~45k lines of implementation, and 50k lines of tests. This was made possible by moving from a homegrown auth system to Clerk, as well as consolidating some Cloudflare workers, and other basic stuff. Not as fun as creating the tech debt in the first place, but much more satisfying. Open source repo if you…

Damn I just deleted another 29k loc https://github.com/VibesDIY/vibes.diy/pull/635

Code slows you down, always worth cleaning up. Yes, the business case is aligned with both the past bloat, and the current cleanup.

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

#316

Post by lkbm »

joker99 wrote: post #116
jll29 wrote: post #104

From the report, it sounds like a good thing, for the product and the team morale. Strangely the math looks such that they could hire nearly 1 FTE engineer that works full time only on "little issues" (40 weeks, given that people have vacations and public holidays and sick time that's a full year's work at 100%), and then the small issues could be addressed immediately, modulo the good vibes created by dedicating the…

The unkind world we live in would see this role being abused quickly and a person not lasting long in this role. For one, in the wrong team, it might lead to devs just doing 80% of the work and leaving the rest to the janitor. And the janitor might get fed up with having to fix the buggy code of their colleagues. I wonder if the janitor role could be rotated weekly or so? Then everyone could also reap the benefits of…

I've had on-call roles where the idea was that in your spare time you worked on bug fixes (specifically the ones causing the most on-call noise).

Unfortunately, that on-call was so overwhelmed that you were lucky to be able to handle all the alerts/crises, let alone having spare time to fix the root causes.

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

#317

Post by RHSeeger »

AdamN wrote: post #209
RHSeeger wrote: post #57

Earlier quoted context omitted.

Bugs have priorities associated with them, too. It's reasonable for a new feature to be more important than fixing a lower priority bug. For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.

IMHO the best way to deal with that situation is to mark the bug as wontfix. Better to have a policy of always fixing bugs but be more flexible on what counts as a bug (and making sure the list of them is very small and being actively worked on).

But it's not "wont fix", because it will get fixed when there's nothing of a higher priority. And it's priority could change at some point.

> Better to have a policy of always fixing bugs but be more flexible on what counts as a bug

I just disagree with this. It's entirely possible for something to not work correctly, but that fact be unimportant at the moment (or less important than something else).

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

#318

Post by triyambakam »

kubb wrote: post #169
triyambakam wrote: post #27

Earlier quoted context omitted.

> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. Now I find that odd.

You might get humbled by overwhelming complexity one day. Enjoy the illusion of perfect insight until then.

I didn't say it must be always correct

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

#319

Post by jorvi »

ChrisMarshallNY wrote: post #233
jorvi wrote: post #228

Earlier quoted context omitted.

Yeah, "no bug should take over 2 days" tells me you've never had a race condition in your codebase.

I'm sure that you're right. I'm likely a bad, inexperienced engineer. There's a lot of us, out here.

I'm sure your sarcasm is right. You're likely a good, godlike engineer that would fix even the most intractable race conditions within 48 hours. There's a lot of you, out there.

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

#320

Post by ChrisMarshallNY »

jorvi wrote: post #319
ChrisMarshallNY wrote: post #233

Earlier quoted context omitted.

I'm sure that you're right. I'm likely a bad, inexperienced engineer. There's a lot of us, out here.

I'm sure your sarcasm is right. You're likely a good, godlike engineer that would fix even the most intractable race conditions within 48 hours. There's a lot of you, out there.

Have a great day!
Post reply on HN