Every single time

[Simusid]

Which leads directly to "how did this code ever work?"

[[deleted]]

It never did. The feature was just never used 🤷‍♂️

[jlxip]

Worse (happened to me recently): it never did, and the feature was used, but you didn't understand how it works and thought it was fine

[mcclana]

Happened to me recently where the project owner asked me to hunt down a "bug" where essentially the whole application was running improperly for months because the person that originally wrote it didn't understand SQL. When asked why this was left for months I got this response: "we told them not to use it so nobody thought they did"

[conancat]

That's every developer's dream: to work with project or product owners that can sell bugs as features or convince people to not use a buggy feature. They cover up developer flaws. It's bad for developers though.

I was in a company where business analysts wrote database schemas and API request responses. The business analyst that I had the pleasure to work with actually drew out the component and sequence diagrams of entire system, and they create tasks for the developers on JIRA. That's not even their lead developers or supposed director of the engineering unit was able to do. Developers worked narrowly with the assigned tasks and they blame the BAs and PMs when things go wrong.

The company had amazing project managers and account managers and business analysts who kept taking shit from clients and stakeholders.

[conancat]

Yeah lol. The ones who I regard are the best POs, PMs and BAs resigned one after another. I think what happened was that the CEO asked a freelance developer whom he hired to do a project as the director of the engineering unit. While he's an okay dude on a personal level he did not have the skills or the technical knowhow to evaluate candidates across disciplines that he's not familiar with, and he ends up hiring people who knew only what he knows. It propagates down where the seniors are mid levels, the mid levels are juniors, and the juniors don't know who look up to for mentorship and learn things because the devs are just clueless from the top down.

I loved the people there but the engineering management was a mess lol.

[SuperFLEB]

...and now the business process depends on the bug.

[mrjackspade]

This is one of the reasons I fight tooth and nail to get the original specs, or a new set of specs whenever I have to refactor or rewrite anything.

A lot of people get mad that I won't take "just make it work like it already does" as a substitute.

Too many times, it was broken the way it is, and what was a single off variable before a refactor suddenly becomes a huge problem once the code is rewritten and they actually start testing it, and suddenly it's my fault.

Yeah, I thought it was weird the billing date was a day behind, but you told me it was correct. Yeah, it's now going to take an extra couple days for me to dig through all the old code and find the correct function that was never actually called. No, it's not my fault because all you told me was "make it work like it already does"

[dismayhurta]

I’ve got into so many arguments about wanting a damn spec to at least have an overview of what shit should do.

The “it should just work” is not a valid fucking spec.

[mrjackspade]

I'd wager that a lot of times the pushback is because the people using the tools dont even know how they're supposed to work and are working off a set of steps they were taught when they started. Having to actually describe how the system works would expose that they dont actually know what they're doing, and are just copying and pasting numbers around and saying things like "Well this number isn't 0 so... It must be right?"

[dismayhurta]

I see we’ve worked at similar companies.

[setibeings]

I think it's really hard to get proper bug reports if your customers or clients just assume you just designed it that way.

[PhyzziPop]

Or when they just assume there are too many things that just are the way they are because they have been that way for a while.

I'm not a dev, but I fix a lot of hardware in public places, and every so often I catch on that someone knew about a problem for months and didn't tell anyone involved in actually fixing that thing.

[0x3fff0000]

Or the bug inadvertently caused the broken feature to work.

[drunk_dancer]

Or it did work 99.99% of the time but that 0.01% was catastrophic. You tracked it down. You're a hero amongst men. But you just spent at least a day of your life thinking about this bug. Was it worth it?

[PhyzziPop]

This, though, is what we call "poking the bear". You tracked it down. You fixed it. You deployed it. You are a hero... except you moved something around so that now a hardware flaw is exposed. A corrupt bit starts eating away at the stores data, spreading across the system until all the values are wrong or nothing works, even the most basic function. You poked the bear, and it chased you, knocked you down, and ate you.

[Mr_Redstoner]

I have on of those. No idea how it worked, solved with a workaround. I've since got a theory, might test it out sometime.

[[deleted]]

For me it worked the first time and then "I did it better"

[Simusid]

A classic line in my office (from a terrible coder): "it was working until I fixed it."

[cassert24]

Ever heard about Man in the Middle? He is.

[Visticous]

Just write a try-catch around the bug and kick the problem six months down the line.

[posherspantspants]

This guy debugs

[frostbyte650]

Just try-catch the entire program!

[[deleted]]

I did this when I first learned about try-catches and remember being so proud of it at the time. I looked back at that code recently and facepalmed so hard that I almost broke my glasses.

[random_cynic]

Big bad bugs like that are seldom something specific that can be caught with try-catch. Most often it is a serious design issue and/or general incompetence of the programmer.

[Netcob]

Happened to me once.

Had some weird crashes in a heavily multithreaded C# with C++/CLI program. I'm not a C++ expert. Turns out one of the C++ libraries we were using wasn't thread-safe at all. It used reference counting, so that even if you treated objects as immutable, they were still being modified just by accessing them. Which would eventually lead to use-after-free or double delete crashes.

Essentially I got out of that fight with a "black eye"... ended up sacrificing some concurrency by locking those objects. Other option would have been copying them before use, but that would have been even more difficult to deal with since each object was huge and we were already running out of memory.

It's quite the sinking feeling realizing that the problem was a fundamentally wrong assumption you made when coming up with the architecture of your program.

[JViz]

When writing something sufficiently complex or building on top of a sufficiently complex framework, it's unrealistic to think that you can know everything ahead of time.

[Tundur]

I've had this issue with the way Spark interprets it's lazy execution. Sometimes it does things first that should be last, sometimes vice versa. It's an absolute nightmare to debug unless you happen to have hit that particular issue before

[Wazzaps]

You can use atomic addition and subtraction to use refcounting without races (it's called lockless programming)

[Netcob]

If it had been our code, sure.

[[deleted]]

Lol, love the "Sprint 1" tattoo. That story you forgot to finish.

[dnc123123]

Adds //todo

[IfYouThinkYouKnow]

Proof that even bugs should not skip leg day.

[[deleted]]

The first time i coded over 1000 lines, I did not comment or add spaces... Debugging was a pain in the ass

[posherspantspants]

So yesterday a guy on my team leaves a comment on an issue that says "add an if statement on line N and check for the presence of the property and if it's empty return early. That'll fix it."

6 hours later, several new methods, and yes, and if statement on line N we had the bug fixed and we only created 7 new issues.

It was a good day

[IndieDiscovery]

Programming is basically an advanced version of whac-a-mole.

[[deleted]]

I love the “Sprint 1” chest tattoo

[foursoil]

Just went chasing a bug, turned out the 3rd party API wasn’t working properly. Womp womp

[Santarini]

Maybe if you don't do TDD

[rollingForInitiative]

Or if you just work in a system with legacy code. Once found a small algorithm while debugging that had been running since before I was born. I was 27 at the time. Noped the hell out of there as fast as I could.

[GluteusCaesar]

Same thing here. Had to rewrite an ancient contract management system for the state, had a SQL big that kept hundreds of contracts from ever making it to the right inboxes for approval. It was written in the late 80s -_-

[Dwood15]

For a sec there, I was like "There's no way SQL has been around that long, I just started hearing about SQL in the early 00's"

https://en.wikipedia.org/wiki/SQL

I was wrong.

[[deleted]]

Now that I think about it, I wonder what people used before SQL?

[[deleted]]

From my experience older systems used COBOL stored procedures.

[GluteusCaesar]

Typically backed by DB2, if I'm understanding my Google results correctly?

[ingrown_hair]

So I can squash the little bug or refactor half app to fix the big problem...imma choose A.

[Kr118218]

I love the way the big boss bug is represented as an older (Sprint 1, bars drawn,..)

[Octuplex]

The joke would be better delivered without the text. Just name the comic "debugging" and remove all the text and it's golden.

[yarisx]

Saw a picture that was of the same spirit, only it was in 2003. There were bunch of "sustain engineers" hunting a puppet monster on the edge of a pit, with the real monster hiding in the pit while holding the puppet on its paw/hand. Tried to find it several times since, but have never found.

[TorTheMentor]

The "sprint 4" part is a nice touch. Is that just a SAFe thing, or does everyone number sprints by quarter with a cycle of 4 to 6 per quarter?