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

11–20 of 356 posts

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

#11

Post by mulquin »

entropie wrote: post #8

I wanted to take a look at some of these bug fixes, and one of the linked ones [1] seems more like a feature to me. So maybe it should be the week of "low priority" issues, or something like that. I don't mean to sound negative, I think it's a great idea. I do something like this at home from time to time. Just spend a day repairing and fixing things. Everything that has accumulated. 1: https://github.com/google/perf…

To be fair, the blog post does not explicitly say anywhere that the week was for bug fixes only.

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

#12

Post by asdfman123 »

ls-a wrote: post #10

189 bugs in one week. How many employees quit after that?

They said they only pick bugs that take 2 days to fix.

Places where you can move fast and actually do things are actually far better places to work for. I mean the ones were you can show up, do 5 hours of really good work, and then slack off/leave a little early.

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

#14

Post by BurningFrog »

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!!

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

#15

Post by hastily3114 »

We do this too sometimes and I love it. When I work on my own projects I always stop and refactor/fix problems before adding any new features. I wish companies would see the value in doing this

Also love the humble brag. "I've just closed my 12th bug" and later "12 was maximum number of bugs closed by one person"

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

#16

Post by ChrisMarshallNY »

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 quite easy to find.

Once I find the cause of a bug, the fix is usually just around the corner.

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

#18

Post by jchrisa »

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 like to read this sort of thing: https://github.com/VibesDIY/vibes.diy/pull/582

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

#19

Post by Celeo »

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!!

Depending on the size of the team/org/company, working on anything other than the next feature is a hard sell to PM/PO/PgM/management.

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

#20

Post by chii »

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 find most bugs take less time to fix than it takes time to verify and reproduce.
Post reply on HN