Live data from Hacker News

We stopped roadmap work for a week and fixed bugs

lalitm.com

261–270 of 356 posts

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

#261

Earlier quoted context omitted.

LLMs have helped me here the most. Adding copious detailed logging across the app on demand, then inspecting the logs to figure out the bug and even how to reproduce it.

I did that once: logging ended up taking 80% of the CPU leaving not enough overhead for everything else the system should do. Now I am more careful to figure out what is worth logging at all, and also to make sure disabled logs are quickly bypassed.

we've gotten into adding verbosity levels in logging where each logged event comes with an assigned level that only makes it to the log if it matches the requested log level. there are times when a full verbose output is just too damn much for day-to-day debugging, but is helpful when debugging the one feature.

i used to think options like -vvv or -loglevel panic were just someone being funny, but they do work when necessary. -loglevel sane, -loglevel unsane, -loglevel insane would be my take but am aware that most people would roll their eyes so we're lame using ERROR, WARNING, INFO, VERBOSE

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

#262
post #143

Earlier quoted context omitted.

I've had to inform leadership that stability is a feature, just like anything else, and that you can't just expect it to happen without giving it time. One leader kind of listened. Sort of. I'm pretty sure I was lucky.

Ask them if they're into pro sports. If so (and most men outside of tech are in some way), they'll probably know the phrase "availability is the best ability".

Or just look at your car. Heated seats are sexy in the short term, but boring old reliability and predictability win out long term.

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

#265
post #202

Earlier quoted context omitted.

> a removal attempt is the most effective and cost efficient way to find out whether the ting can be removed Cost efficient for your team’s budget sure, but a 1% chance of a 10+ million dollar issue is worth significant effort. That’s the thing with enterprise systems the scale of minor blips can justify quite a bit. If 1 person operating for 3 months could figure out what something is doing there’s scales where that…

If there is a risk of a 10+ million dollar issue there is also some manager whose job is to overreact when they hear the announcement that someone wants to eliminate thing X, because they know that thing X is a useful part of the systems they are responsible for. In a reasonable organization only very minor systems can be undocumented enough to fall through the cracks.

In an ideal world sure, but knowledge gets lost every time someone randomly quits, dies, retires etc.

Stuff that’s been working fine for years is easy for a team to forget about, especially when it’s a hidden dependency in some script that’s going to make some process quietly fail.

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

#266

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…

I agree completely. Also it gives mental excuse to not fix bugs now and leave it for the upcoming bug fix week. Specially if there's any kind of celebration of what was achieved during bug fix week.

It's also patronizing to the devs. "Internal survey shows devs complain about software quality, let's give them a week every quarter and the other 11 we do whatever we want". What needs to change here is leadership being honest about business, as sometimes fixing bugs is simply not important. Sure sure it depends on the bug... I am talking about when devs complain about having a huge number of bugs in the backlog (most of them low impact) or whatever something that only affects a small percentage. Another strategy here would be to properly surface the impact of said bugs to users / customers... until you do this, nobody has a reason to care.

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

#268

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…

Two thoughts:

- This bug genuinely sounds like low priority.

- This organization seems to operate assuming unforeseen problems will never pop up. That is unwise.

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

#269
post #95

Earlier quoted context omitted.

Yes. I often just copy the whole core dump, and feed it into the prompt.

And this kids is how one bug got fixed and two more were created

There's a huge difference between using an LLM to assist you versus letting it just do all the work for you. Your implication that they're the same, and that the previous commenter let the LLM do the work, is lazy.

ChrisMarshallNY only said they fed the dump into the LLM. They said nothing about using the LLM to write the fix.

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

#270

Earlier quoted context omitted.

i got lucky at my last shop. b2b place for like 2x other customer companies. eng manager person (who was also like 3x other managers :/ ) let everything get super broken and unstable. when i took lead of eng it was quite an easy path to making it clear stability was critical. slow everything down and actually do QA. customer became super happy because basically 3x releases went out with minimal bugs/tweaks required.…

It's interesting how misaligned your effort is. You put effort into writing an unnecessary tldr on a short post, but couldn't be bothered to properly Capitalize your sentences in order to ensure the readability. Weird.

> couldn't be bothered to properly Capitalize your sentences

i changed my iphone settings to not auto-capitalise words

i put effort into my ostensible laziness

Post reply on HN