Walked into the office in the afternoon, everyone was kinda panicking
Asked what was going on, well, the ticket system is not working anymore, can't put in any new tickets.
So I started to look for the issue as well, checked the system and... The last tickets' IDs were at ~32k. Ha. Looked into the source code and, sure enough, they used a data type with an upper limit of... 32k. So when trying to get a new ticket ID it just crashed and burned.
Quickly changed the data type and stopped the office panic in around half an hour.
Memorable not because of how tough the bug was, but because of the impact and the simplicity of the fix

Early in my database developer career, I started a new job at a mortgage company. I was poking around the code, just getting familiar with things.

One script identified properties in certain states/territories for special handling:

AND STATECD IN (‘PR’, ‘HI’, ‘AL’)

I thought “Puerto Rico, Hawaii, and ALABAMA?? One of these things is not like the other…”

Yeah, that was supposed to be Alaska (AK)… But they’ve been special-handling properties in Alabama for years.

At my first big boy job at a start up with only 50 users, we noticed we had cloud cost spikes about 20x larger than we were expecting. I remember spending all night debugging it, checking the requests as they go through.

The culprit? Someone left an async on a UseEffect with a variable that was regularly updated as a parameter.

In other words: every time a request was fired, the variable would change… so the function would sense the variable changed and fire it again, and so on.

Felt like a total hero.

Fixed a bug in my emulator that was completely breaking almost every program I ran on it.

Turns out the virtual ALU set its arithmetic flags (zf, nf) even when a non-arithmetic operation was run.

Buffer usage for simple file operation in python.

What the code "should" do, was using I think open or write a stream with a specific buffer size.

Buffer size should be specific, as it was a stream of a multiple gigabyte file over a direct interlink network connection.

Which should have speed things up tremendously, due to fewer syscalls and the machine having beefy resources for a large buffer.

So far the theory.

In practical, the devs made one very very very very very very very very stupid error.

They used dicts for configurations... With extremely bad naming.

configuration = {}
buffer_size = configuration.get("buffering", int(DEFAULT_BUFFERING))

You might immediately guess what has happened here.

DEFAULT_BUFFERING was set to true, evaluating to 1.

Yeah. Writing in 1 byte size chunks results in enormous speed deficiency, as the system is basically bombing itself with syscalls per nanoseconds.

Kinda obvious when you look at it in the raw pure form.

But I guess you can imagine how configuration actually looked....

Wild. Pretty wild. It was the main dict, hard coded, I think 200 entries plus and of course it looked like my toilet after having an spicy food evening and eating too much....

What's even worse is that none made the connection to the buffer size.

This simple and trivial thing entertained us for 2-3 weeks because *drumrolls please* none of the devs tested with large files.

So as usual there was the deployment and then "the sudden miraculous it works totally slow, must be admin / it fault" game.

At some time it landed then on my desk as pretty much everyone who had to deal with it was confused and angry, for understandable reasons (blame game).

It took me and the admin / devs then a few days to track it down, as we really started at the entirely wrong end of the problem, the network...

So much joy for such a stupid thing.

Was working on a system we planned on to deliver to a hospital
basically it was meant for controlling and monitoring pactions coming in and attendance time from the staff

Got it off the ground well and got to where the system was supposed to update room status
occupied/free then horror started
the db was not setting the room free after clearing a client off the list... room remained occupied and this kept on happening for 6 months and I was so focused on fixing the db models thinking thats where the problem was....

1 day after leaving the project for several months i just revisited the project randomly and started going through the whole code base trying to make sense of what was happening as there where no errors generated..
I had to verify the whole system logic... and that day i figured out what was happening...
upon adding a client to a room the system was also creating a duplicate room so when the function for setting the room free executes it would set the duplicate room free and not the actual room and the system would pick the room with occupied state causing the user not being able to assign new pactions to the room

Solving this brought so much relief coz it required so much work just to solve what seemed to be a minor issue

"Most memorable bug you fixed?"

A recent instance happened in one of my Scratch projects, and the bug involved "Infinities."

I had an opportunity to teach kids programming, and it involved Scratch. So, to have something to show those kids at least, I decided to make a small game.
In that game, I had an object that takes some time before appearing after being cloned (i.e., instantiated.) The duration was calculated by dividing a constant with a variable:
[Wait for ((3) / (variable)) seconds]
The bug is that I forgot about the case where 'variable' can be 0, which is classic and insignificant.

Well, the thing is that I learned two things the hard way:
1: Scratch is very flexible about integers and floats (e.g., at one second, it looks like an integer, but one operation later, it's a float.)
2: Scratch does not provide any 'runtime errors' that can crash the project.

In other languages, similar "wait" methods take "milliseconds" in an integer, so it would have barfed out a "DivideByZeroException" or something. But Scratch was so robust against project-crashing behavior that it literally waited for f*<king "infinity seconds," effectively hanging that clone without warning or runtime errors. This masked my bug. It took way too long to debug that s#!+.

Don't blanket-mask any errors.

I made something work that wasn't working

Was working on a nestjs api and building it on a starter template. After a year of work nest framework has been upgraded by two major version and api is unupgradable and in dependency hell.

Solved it by doing a transplant into new codebase built using cli. Only took two days. Everything went better than expected.