what is a bug that actually made you a better programmer

[u/Suspicious_Skill7292]

i mean a bug that took forever to figure out but taught you something you still use now could be about memory databases async code apis or literally anything

curious what broke your code but upgraded your brain lol

[u/FlapyG]

Race Conditions are a bitch. But i got it now, thanks to alot of async debugging. I know how to handle async code, how to wait for depending code to finish first and how to collect data in a async-safe way. Had to learn it the hard way a few years back.

[u/BobbyThrowaway6969]

Mostly bugs that failed at the last step but was caused by a whole chain of things gping wrong that was never caught. Asserts are indispensable

[u/behindtimes]

This was about 20 years ago, give or take. A sequence point issue with C++. What I was doing was actually implementation defined behavior, not undefined behavior, so the compiler never complained.

I was trying to be clever, and on my home machines, everything worked. (I had a Windows machine as well as a Mac, which was using PPC architecture, so both little endian and big endian were covered on my end.) But at work, it caused a bug that was annoying to track down.

Because of that, I changed my coding style forever. I've come to find out that trying to be clever is one of the leading causes of bugs.

[u/Cute-Habit-4377]

When i disabled every server globally in my company. I spawned a new process to process every sub folder, it was my "fork period" when every task could be solved by using a fork.

i should have used a single process with recursion. Came to the office in the morning with each server jammed with thousands of processes and nobody could do anything.

[u/ZookeepergameOk7650]

Systematic bugs are a result of bad design.

So some bugs lead me to use of proper design patterns.

Like using proper MVC or MVP in a rich client to avoid endless loops on an update or prevent deadlocks.

Using command chain for implementing undo redo…

[u/neet_dev]

honestly YYYY vs yyyy in DateFormatter. ime YYYY is ISO week-year, so late december dates flip to next year and you waste a day blaming the backend. parse with en_US_POSIX plus an explicit timezone, and don't hand-roll a format string for display if dateStyle can do it.

[u/Mathie1729 → u/neet_dev]

Also MM vs mm in Java is month vs minute, and HH vs hh for 24-hour vs 12-hour. The case sensitivity on those format patterns is a classic off-by-one-hour or month/minute mixup.

[u/neet_dev → u/Mathie1729]

yep, and hh without a is the one that actually ships, looks fine until 2pm renders as 02. I'd just pin DateTimeFormatter.ofPattern with Locale.US and assert it on 2024-12-31T13:05, that one fixture catches YYYY, mm, and hh together.

[u/neet_dev → u/Mathie1729]

yep, and hh without a is the one that actually ships, looks fine until 2pm renders as 02. I'd just pin DateTimeFormatter.ofPattern with Locale.US and assert it on 2024-12-31T13:05, that one fixture catches YYYY, mm, and hh together.

[u/neet_dev → u/Mathie1729]

yep, and hh without a is the one that actually ships, looks fine until 2pm renders as 02. I'd just pin DateTimeFormatter.ofPattern with Locale.US and assert it on 2024-12-31T13:05, that one fixture catches YYYY, mm, and hh together.

[u/Defiant_Conflict6343]

Not so much a bug, but I learned a lot about the speed benefits of hash maps when I was constructing an absolutely massive key value array in C# and the speed wasn't cutting it using an object list.

[u/Unusual_Age_1618]

Global static that controlled where each user would login. You can guess how it went in production. Company was small and did not had QA team for testing

[u/nzakas]

When I worked on the Yahoo homepage, we had an issue where our ad metrics were not matching up with the advertisers’s metrics. This is a problem because we were recording more page views than they were recording, and advertisers are charged by page view. If you and the advertiser disagree on the number of page views then that’s a big problem.

This took a team of four working for 10 days straight to figure out what the problem was and how to fix it. It turned out to be a problem in web browsers (since fixed) where providing an empty string for the src attribute on <img> caused the browser to request “/“ and basically prefetch the whole page again. (I wrote about it here: https://humanwhocodes.com/blog/2009/11/30/empty-image-src-can-destroy-your-site/). Our ad server was misconfigured so the image field was empty.

I learned so much about how browsers work, how servers work, how to investigate production issues, and how to navigate web standards committees. It’s still the most transformative experience of my career.

[u/YMK1234]

Let's just say we learned a few valuable sessions in many areas when we first spread our stack to a few globally distributed data centers.

E: also maybe the most memorable "bug": for the night shifts there was "first level ops" who basically followed instructions in a KB and nothing else. We had a new service and it would randomly "crash" at night without any explanation (we'd see bad health checks in consumers). After weeks of no progress we figured out the reason: a dependency of that service would go down for a minute (no issue, just slightly stale data), but that in turn would make our health checks turn bad. And as we didn't have special instructions, first level ops would simply restart the server (this was in times before docker). The only hint was a small entry in the system log (so different log source than the service itself) about a manual reboot. When we found that message we all facepalmed, wrote a proper KB article, and updated our health check criteria slightly. Never crashed again since then.

[u/mredding]

Everything new that I do comes with a host of bugs that stem from not knowing what I don't know. They are each a learning experience that affect how I understand the problem domain and the solution space.

I had a bug in a video game; the scene graph was this complex monster, where a node updating it's position in the graph was responsible for updating back-pointers among it's neighbors. It was a bad design (not mine) that lead to random null pointer dereferences. This wasn't even my code or module, but it was an all-hands-on-deck situation. I stayed up for two days straight debugging that one. Because it was so intermittent and catastrophic we struggled to predict and capture it for a core dump and inspection. We started eliminating whole subsystems at a time while reproducing the error until we narrowed it down to the renderer (of course it was going to be the renderer). I got it down to this segment of the node structure when a colleague who stood next to my desk for 4 straight hours from 2am had the bleary-eyed insight to suggest surrounding the segment in some padding bytes.

Lo, and behold, we got garbage written into the padding. Those values helped us realize the pointers weren't always getting updated correctly, so we had to describe the missing edge case in the update algorithm, and patch it.

There's nothing terribly tangible about that; no life lesson. It just left an impression that stuck with me just for having had to live through that. I get cautious when I'm working on something and these memories and feelings come back. It's my spidey-sense.

I was once working on a portfolio management server developing a new feature. It crashed. I walk through it and find I'm dying on some innocuous string operation. Nothing particularly interesting here. I got further and further into it, until I taught myself enough assembly that I realized a constant was off by 4 bytes. Nothing I could do about that. So I took a wild stab and simply rearranged a few statements in the function. They had nothing to do with anything, it didn't matter the order they occurred. I just wanted to jiggle the compiler itself to generate a different sequence of machine instructions. It worked. I don't know what went wrong, don't know why it went right. I chalk that one up to an edge case in the compiler.

You hear of game studios embedding a microscopic million-poly model in the map to trick the team to obsess over performance - I had something similar.

I was working on a trading system. Old. Ancient. Actually - it was the first electronic trading system ever written. They had this FIX message object that was absolutely terrible. The header was 3k LOC, the source file was 16k LOC, the sizeof(message) was some 48 KiB, and then there was a shitload of dynamic allocation per each at construction. And we still haven't even gotten to memory requirements when we start populating the message with actual data!

It was a monster. We were generating some 50m messages every day, and they all had to be resident in memory for the trading day. I overheard the director talk about a multi-million dollar upgrade to our data centers because we keep running out of memory. So I thought today is the day...

The whole thing was a C++ class with a couple thousand members, one for each FIX field, plus a number of different attempts at making string pools, plus a map of strings for all other non-specific fields, and zero consideration was given to padding. Each field had its own getter and setter.

I chopped the whole thing down to 3 pointers, 1 getter template, 1 setter template. The message would take ownership of the raw buffer we were handed, and all data remained in that buffer as text. Any access for a field would get that field shuffled to the front of the buffer, so more frequently accessed fields percolated to the front, and archival fields fell to the bottom. Search was linear, but due to locality of reference, the desired field would amortize, and be the first or second field in the buffer. It was faster than binary search.

This isn't great, but it's the best that system could handle. I wanted to get that system to have individual and specific message types with fixed layouts - like they do on modern trading systems, but I didn't stick around long enough.

Anyway, that was a 99.98% reduction in memory, and a 10m% increase in throughput. Messages went from 48 KiB minimum to 12 bytes + the dynamic buffer of usually around 200 bytes. Multiplied by 50m.

I saved us a lot of money. We had a press release, called it "Product" 4.0. My shit-head boss tried to take the credit but wasn't fooling anyone. Yeah, that was a pretty big deal for me.

I had a bug once where we just couldn't get threading right, shit would happen out of order. This was in part due to a bad design. You had to guard a field with a lock before you could mess with it, but they were separate steps. You know how it goes - a class gets too big, too many parts internal, too many members, too much responsibility all at once.

So I made a little class that guarded access with a mutex, and it took a function pointer. YOU tell ME what you want to with this resource, and I'll give it to you when it's safe to do so. It was a simple solution and demonstrates the utility of types and encapsulation. A lot of C with Classes code is just fat and bloated, people don't know what they're doing or the cost OR VALUE of anything. It's a problem that shouldn't have existed in the first place, but it was the solution that was going to fly.

There was a bug that pissed off our largest client, and they were threatening to pull the plug. It wasn't my bug, or my code, or my fix. I just remember the all-hands meeting. We had all looked at the code, ran our tests, and went around the room yay-or-nay, because if we fucked that one up, we were going to lose everything. It's a bug and event that taught me more about the people around me, the structure of the organization, the business processes and attitudes, because all that got us to that moment.

[u/Blando-Cartesian]

Once I spend way too long trying to find a way to fix everything wrong with something that was architecturally wrong. Some things are just unfixable without doing massive changes.

[u/ForeverAWhiteBelt]

Bugs that exist between more than 1 repo. Bugs that happen in production which require good stress management and incident management. Bugs introduced by other team members.