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

171–180 of 356 posts

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

#171

Post by ls-a »

toast0 wrote: post #90
ls-a wrote: post #74

Earlier quoted context omitted.

That's what I'm saying. Nothing takes 2 days to fix meaning it takes more time

Oh. Well, I've done easy fixes too. There's plenty of things that just need a couple minutes, like a copy error somewhere. Or just an hour or two. I can't find it anymore, but I've run into libraries where simple things with months didn't work, because like May only has three letters or July and June both start with Ju. That can turn into a big deal, but often it's easy, once someone notices it.

If your goal is to fill green github squares then fine

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

#173

Post by ChrisMarshallNY »

ZaoLahma wrote: post #170
ChrisMarshallNY wrote: post #136

Earlier quoted context omitted.

I've found the opposite to be true, in my case.

For me the longer I work, the worse the bugs I work with become. Nowadays, after some 17 years in the business, it's pretty much always intermittently and rarely occurring race conditions of different flavors. They might result in different behaviors (crashes, missing or wrong data, ...), but at the core of it, it's almost always race conditions. The easy and quick to fix bugs never end up with me.

The reward for good work, is more work.

I tend to mostly work alone, these days (Chief Cook & Bottle-Washer).

All bugs are mine.

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

#174

Post by lll-o-lll »

ZaoLahma wrote: post #170
ChrisMarshallNY wrote: post #136

Earlier quoted context omitted.

I've found the opposite to be true, in my case.

For me the longer I work, the worse the bugs I work with become. Nowadays, after some 17 years in the business, it's pretty much always intermittently and rarely occurring race conditions of different flavors. They might result in different behaviors (crashes, missing or wrong data, ...), but at the core of it, it's almost always race conditions. The easy and quick to fix bugs never end up with me.

Yep. Non-determinism. Back in the day it was memory corruption caused by some race condition. By the time things have gone pop, you’re too far from the proximate cause to have useful logs or dumps.

“Happens only once every 100k runs? Won’t fix”. That works until it doesn’t, then they come looking for the poor bastard that never fixes a bug in 2 days.

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

#175

Post by gregoriol »

demaga wrote: post #151
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.

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.

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

#176

Post by ChrisMarshallNY »

lll-o-lll wrote: post #174
ZaoLahma wrote: post #170

Earlier quoted context omitted.

For me the longer I work, the worse the bugs I work with become. Nowadays, after some 17 years in the business, it's pretty much always intermittently and rarely occurring race conditions of different flavors. They might result in different behaviors (crashes, missing or wrong data, ...), but at the core of it, it's almost always race conditions. The easy and quick to fix bugs never end up with me.

Yep. Non-determinism. Back in the day it was memory corruption caused by some race condition. By the time things have gone pop, you’re too far from the proximate cause to have useful logs or dumps. “Happens only once every 100k runs? Won’t fix”. That works until it doesn’t, then they come looking for the poor bastard that never fixes a bug in 2 days.

My first job was as an RF (microwave) bench technician. My initial schooling was at a trade school for electronic technicians.

It was all about fixing bugs; often, terrifying ones.

That background came in handy, once I got into software.

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

#177

Post by darkwater »

auggierose wrote: post #168
darkwater wrote: post #148

Earlier quoted context omitted.

> A bug description at the beginning is some observed behaviour that seems to be wrong. Or not. A bug description can also be a ticket from a fellow engineer who knows the problem space deeply and have an initial understanding of the bug, likely cause and possible problems. As always, it depends, and IME the kind of bugs that end up in those "bugathons" are the annoying "yeah I know about it, we need to fix it at som…

That just means that somebody else has already started the process of understanding the bug, without finishing it. So what?

So you can know before starting to work on the ticket if it's a few minutes boring job, if it could take hours or days or if it's going to be something bigger.

I can understand the "I don't do estimates" mantra for bigger projects, but ballpark estimations for bugs - even if you can be wrong in the end - should not be labelled as 100% impossible all the times.

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

#178

Post by lll-o-lll »

ChrisMarshallNY wrote: post #176
lll-o-lll wrote: post #174

Earlier quoted context omitted.

Yep. Non-determinism. Back in the day it was memory corruption caused by some race condition. By the time things have gone pop, you’re too far from the proximate cause to have useful logs or dumps. “Happens only once every 100k runs? Won’t fix”. That works until it doesn’t, then they come looking for the poor bastard that never fixes a bug in 2 days.

My first job was as an RF (microwave) bench technician. My initial schooling was at a trade school for electronic technicians. It was all about fixing bugs; often, terrifying ones. That background came in handy, once I got into software.

I started life as an engineer. Try reverse engineering why an electrical device your company designed (industrial setting, so big power), occasionally and I mean, really really rarely, just explodes; burying its cover housing half way through the opposite wall.

Won’t fix doesn’t get accepted so well. Trying to work out what the hell happened from the charred remains isn’t so easy either.

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

#179

Post by stevoski »

stevoski wrote: post #102

I’m a strong believer in “fix bugs first” - especially in the modern age of “always be deploying” web apps. (I run a small SaaS product - a micro-SaaS as some call it.) We’ll stop work on a new feature to fix a newly reported bug, even if it is a minor problem affecting just one person. Once you have been following a “fix bugs first” approach for a while, the newly discovered bugs tend to be few, and straight forward…

I wrote up my thoughts on this into a longer post: https://killthehippo.com/posts/fix-bugs-or-add-new-features

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

#180

Post by pjmlp »

zeroCalories wrote: post #147
k4rli wrote: post #111

Earlier quoted context omitted.

Imagining that the software will be shipped with hardware, that has no internet access and therefore cumbersome firmware upgrades, might be helpful. Avoiding shipping critical bugs is actually critical so bricking the hardware is undesirable. Example: (aftermarket) car headunit.

This type of testing is incredibly expensive and you'll have a startup run circles around you, assuming a startup could even exist when the YC investment needs to stretch 4x as far for the same product. The real solution is to have individual software developers be licensed and personally liable for the damage their work does. Write horrible bugs? A licencing board will review your work. Make a calculated risk that d…

The kind of relates to proper Engineering titles, unfortunely many countries don't have a legal system in place for those that decide to call themselves engineers without going through the exam, and related Order of the Engineer.
Post reply on HN