The Five Stages of Encountering Bad Code

Level 1: Not Me!

Imagine you walk into your classroom and see crayon scribbles all over the whiteboard. You’re shocked and annoyed and shout, “Who made this mess?!” You’re thinking someone is definitely in trouble. Then a scary thought hits you – wait, did I do this by accident? You try hard to remember if you might have been doodling and forgot. You even start to sweat a little, worried the teacher will say you did it. But then the teacher checks the security camera and finds out it was actually your friend Sammy who did the scribbling during recess. Suddenly, you feel a huge wave of relief. You’re so happy it wasn’t you that, in your mind, there might as well be confetti falling from the sky and a big parade with a banner that says “NOT ME!” You might not throw a real party, but inside you’re jumping for joy because you’re not the one getting blamed. This comic is funny in the same way: it shows a programmer who finds a big mess in the code, is scared for a moment that he might have caused it, and then celebrates like it’s the best day ever when he finds out he didn’t do it. It’s like when you’re just really, really glad you’re not the one who broke something!

Level 2: The Blame Game

Let’s break down what’s happening in simpler terms. The developer in the comic finds some code that looks really bad – we’re talking confusing, ugly, “what on earth does this do?” code. In software, that’s often called a code smell: a hint that something might be wrong with the design or quality. For example, maybe there’s a function with 300 lines of convoluted logic and a comment like // TODO: fix this later. This kind of kludge is a sign of TechnicalDebt, meaning the last programmers took a shortcut that solved a problem quickly but left messy code behind to clean up eventually. Now “eventually” has arrived, and our developer is stuck looking at this nasty LegacyCode (old code inherited from the past) wondering how it ever passed a CodeReview. They literally say, “Who wrote this crap?” which is a pretty harsh way of saying "This code is terrible and I want to know who is responsible." It’s a DeveloperPainPoints moment – nobody likes debugging a hairy, mysterious function that’s breaking things.

So what can they do? Enter the tool git blame. Git is the popular version control system that developers use to track every change in the codebase. The git blame command is like a detective gadget: it shows, for each line in a file, the last commit that modified that line and who made that commit. In other words, it tells you who last touched a piece of code. Developers run git blame on a file to find the culprit behind a questionable line. It’s essentially playing code detective. If our dev sees a weird line on line 47 of utils.py, they might run something like:

git blame utils.py -L47,+1

This will output the commit hash, author name, and date for line 47 of utils.py. For example, it might print:

d34db33f (Alice 2020-02-15 09:23:42 +0200 47)     result = quickFix(temp, true)

From this, our developer learns Alice was the last person to change that line, back in February 2020, under commit d34db33f. Aha! Now they know who wrote (or at least who last edited) “this crap.” In many dev teams, this is where the BlameGame begins. Maybe they’ll ping Alice and say, “Hey, I saw you touched this function last, any idea why it’s doing X?” In a healthier scenario, this is just for understanding context. But often it’s used in frustration, essentially pointing a finger: “Alice, you broke this!” That’s why it’s literally called git blame – it can encourage blaming people. (Fun fact: some folks alias git blame to git praise to sound nicer, but the function is the same.)

Now the funny twist in the comic is when the developer suddenly worries “Was it me?” You can imagine them checking the author name on that git blame output and dreading seeing their own name. This happens more often than you’d think! As a junior dev, the first time you comb through production code, you might stumble on a horrendous function and rant about it, only to discover via git blame that you wrote it months ago when you were rushing a hotfix. Cue the face-palm. Developers often forget the code they wrote, especially if they were sleep-deprived or under pressure. There’s even a saying: “Any code you wrote more than 6 months ago might as well have been written by someone else.” So that moment of introspection is very real – the comic exaggerates it as the character literally sweating while the screen loads, dreading that their own username will pop up. It’s a form of DeveloperSelfDeprecation: we joke that we write crap code too, especially our past selves.

In the comic, finally the git blame proves it was not our hero’s fault. Someone else’s name is on that awful commit. Instantly the worry lifts, and instead of feeling guilty, the developer basically goes “Phew, not me!” They don’t actually throw a party in real life, of course, but inside they’re super relieved. This is illustrating a common behavior: rather than immediately thinking “How do we fix this code?”, a lot of us first think “Please don’t let this be my fault.” It’s a bit of a selfish reaction, but it’s human. CodeOwnerDenial is when you’re quick to deny that you had anything to do with bad code. The comic just takes that to an extreme by showing a literal parade with a huge “NOT ME” sign. It’s poking fun at how developers sometimes care more about avoiding blame than solving the problem at hand. In reality, good teams try to avoid a blame culture – the focus should be on CodeQuality and improvement, not shaming whoever wrote a bug. But as every programmer learns, when the pressure is on, the blame game can be tempting. This comic is a lighthearted reminder: we’ve all played detective with git blame, we’ve all had that heart-stopping moment of possible self-blame, and we’ve all felt that secret joy when it turns out to be someone else’s mess to clean up.

Level 3: The Blame Parade

Dev: "WHO WROTE THIS CRAP?"
(squints at commit history)
Dev: "Wait... was it me?"

This comic strip captures a ritual every battle-worn developer knows too well. You stumble upon some atrocious piece of legacy code – the kind of spaghetti logic that triggers immediate rage. Your first instinct? Run git blame like a crime scene investigator, looking to pinpoint which poor soul to hold responsible. It’s the BlameGame of debugging: scanning the line-by-line history in the repository to find the culprit. In theory, version control tools like Git provide git blame to help understand code history and improve CodeQuality. In practice, we often wield it to find a name and yell "Who wrote this?!" as if naming and shaming will miraculously fix the CodeSmells.

But the humor (and horror) here lies in the next phase of this drama: the icy chill of developer_introspection when a tiny voice whispers, "Could I have been the one who wrote this garbage?". Every senior engineer has that flashback to a 3 AM coding marathon, furiously patching a prod issue with a quick hack and promising to "refactor later". Later is now – and that hastily written workaround might be staring back from the screen. The comic shows our developer sweating bullets at the keyboard because deep down, we all dread the day git blame points that big accusing finger → right at us. It’s a moment of impostor syndrome meets Murphy’s Law: if a piece of code is truly horrendous, chances are non-zero you authored it under duress. (As the old joke goes, TechnicalDebt is the debt most likely to come due the very week you forgot it existed.)

Then comes the punchline: the git blame results finally load... and hallelujah! It was not me after all. Cue the absurdly over-the-top celebration panel – confetti cannons, balloons, a one-person marching band, and a giant foam finger proclaiming "NOT ME!" This is the blame_shift_parade in full effect. The developer’s relief is so tangible it’s like a carnival rolled through the office. The comic exaggerates what every developer feels internally upon dodging responsibility for a bad commit. Instead of a quiet sigh of relief, it’s depicted as a gaudy victory parade. It’s funny because it’s true: in many dev cultures, finding out someone else wrote the infamous code triggers a guilty little fist-pump internally. You’re off the hook! No awkward apologies in the next CodeReviews, no nightmarish refactor assignment of your own making. Just the joy of code_owner_denial with a sprinkle of schadenfreude.

Of course, the dark side of this humor is that blame culture itself is a toxic habit. Seasoned devs (the cynical veterans among us) recognize that throwing a "Not Me" party doesn’t actually improve the code. That awful method is still in the codebase, festering like old food in the fridge. The TechDebt remains unpaid. Yet teams repeatedly fall into this pattern: instead of owning the problem, it’s easier to point fingers and hope the code maintenance lands on someone else’s plate. The comic’s ridiculous Rube-Goldberg celebration is basically saying, “We’d rather invest energy into elaborate blame avoidance contraptions than into cleaning up the mess.” It’s a pointed satire of how organizations deal with bad code. Everyone cheers when the blame lands on a colleague (especially if that colleague left the company — the ultimate scapegoat). Meanwhile, the crappy code stays in production, causing pain for the next poor soul. Ironically, the real “crap” here isn’t just the code — it’s the collective denial of responsibility. The experienced chuckle comes from recognizing this dysfunctional loop. We’ve all seen a critical bug get bounced around: “Must be a library issue, not our code.”, “Maybe the last team introduced this.”, or “It was probably an intern.” – any excuse will do as long as Not Me is the outcome. Blameless culture is preached in post-mortems, but in the heat of a bug hunt, even the best of us have done a little victory dance when the trail leads to someone else’s commit. This comic just takes that secret guilty relief and blows it up to circus-level absurdity. 🎉