When //DELETEME beats //FIXME and //TODO in the Technical Debt Olympics

Level 1: Later, I Promise...

Imagine you’re supposed to clean your messy room, but instead of actually cleaning anything, you stick little notes on the mess saying things like “I’ll take care of this later.” For one pile of toys on the floor, you put a note that says “TODO: put these away soon.” On a broken toy car, you slap a note “FIXME: fix this later.” And on a bunch of trash in the corner, you even put a note that says “DELETEME: throw this out later.” Now you invite your parent to inspect the room. They see all those notes still hanging there days or weeks later – nothing has been cleaned or fixed, you just acknowledged the problems and left them. It’s pretty silly, right? In fact, it’s so silly that we could joke about giving out trophies for it: Third place for the “I’ll do it later” toy pile, second place for the “I know it’s broken but I didn’t fix it” car, and the big first place prize for that trash you knew you should throw away but didn’t. 🏆 The meme is funny in the same way: it shows programmers doing the equivalent in their code – leaving notes instead of actually cleaning up the code – and jokingly treating the worst offender (//DELETEME, the “throw this out later” note) as the champion of bad habits. It’s a way to poke fun at how we sometimes procrastinate, by imagining an Olympic podium where the gold medal goes to laziness in cleaning up code.

Level 2: Never-Ending TODO List

Developers often leave special comments in code to remind themselves (or others) of unfinished work or known issues. These are like little Post-it notes in the source code, usually marked with keywords so they’re easy to find. Three common ones (as this meme highlights) are //TODO, //FIXME, and //DELETEME. Here’s what each of those means:

• //TODO: Stands for “to do.” This comment usually notes a task that needs to be done later. For example, a developer might write //TODO: add input validation above a function. It’s basically saying, “I haven’t finished this part, I plan to come back and do it.” It’s a reminder for an enhancement or a necessary step that was skipped for now.
• //FIXME: Stands for “fix me.” This indicates something is wrong or broken in the code. For instance, //FIXME: handle null values might be next to some code that crashes on null input. The developer is openly acknowledging a bug or flaw but isn’t fixing it at this moment. It’s a way of marking, “This needs a repair eventually.”
• //DELETEME: Literally “delete me.” This one is a developer saying “this code should be removed”. You might see it when some code was temporarily added or quickly hacked in. For example, after debugging, a dev might leave //DELETEME next to a print or console.log call that they used for testing, meaning to remove that line later. It could also tag a block of code that’s been replaced or is no longer needed, essentially, “We don’t actually want this code in the final version.”

On the surface, these comments look helpful – they clearly label issues or future work. The problem (and the reason for the meme’s joke) is that developers often never actually resolve these comments. The //TODO might linger in the code for years, the //FIXME might never get fixed, and that //DELETEME code might never get deleted. They accumulate over time, which is very bad for CodeQuality. It’s like having a checklist that nobody ever finishes.

In software development, when you postpone necessary work like this, we call it technical debt. Think of technical debt like borrowing time: “We don’t fix this now, we’ll fix it later.” Just like real debt, it comes with interest – the longer you wait, the harder and costlier it can be to address. A simple //TODO left undone might turn into a bigger problem later when someone finally needs that missing feature. A //FIXME ignored could mean users encounter a known bug, possibly causing crashes or bad data. And leaving //DELETEME code around (instead of deleting it) can lead to confusion or even introduce bugs if someone accidentally uses that outdated code. In short, these comments are hints of work left incomplete, which will eventually require more effort to clean up – that’s the “interest” on technical debt.

To a new developer (or anyone just learning), seeing these comments can be confusing. Should you do something about them immediately? Often, teams will track these in some way. Some IDEs and code editors highlight TODO and FIXME comments automatically. There are even tools that generate a list of all TODO items in the code, essentially an internal to-do list for the project. The intention is good: you don’t forget about the issue. However, if nobody regularly checks that list or schedules time to work on it, those reminders just sit there. The codebase can become littered with half-hearted notes. This is considered a code smell – a sign that something might be wrong in the code’s maintainability. A clean codebase ideally shouldn’t have a bunch of “please fix this later” comments; if it does, it suggests code needs cleanup or Refactoring. (Refactoring means improving the internal structure of code without changing its external behavior – basically, cleaning it up.) Indeed, each //FIXME or //DELETEME is basically yelling “Refactoring needed here!” to anyone reading the code.

The meme uses an awards podium to rank these comment types by how bad they are when misused. It’s a playful way to say: all of these are bad if you abuse them, but some are worse. Here “worst” means likely to cause TechnicalDebt and frustration. Why put //DELETEME on top as number one? Imagine coming across code where the original programmer themselves wrote “delete this” and yet it’s still there — it feels extra careless! At least with a //TODO, maybe the dev genuinely planned to come back later. With //FIXME, they knew it was wrong but perhaps lacked time. But //DELETEME is like saying “I know this code is useless or harmful” and still leaving it in. That tends to draw the most eye-rolls from other developers. It often happens when someone is unsure if the code might still be needed, so they don’t remove it fully. Instead, they might comment it out and slap a //DELETEME on it, hoping someone (maybe future them, maybe someone else) will confidently delete it later. If no one does, it just sits there, cluttering the file.

For example, consider a snippet of JavaScript code:

function processData(items) {
    // TODO: optimize this loop (it's a bit slow for large lists)
    for (let item of items) {
        processItem(item);
    }
    // FIXME: handle case when items is null or undefined (potential bug)
    let result = calculateResult(items);
    // DELETEME: debugging log, remove this after verifying output
    console.log("Result is", result);  // temporary log for debugging
    return result;
}

In this snippet, you can see all three comments in action:

• The // TODO in the loop notes that the loop isn’t efficient and should be improved later.
• The // FIXME warns that if items is null, calculateResult might crash or behave incorrectly, so that needs a fix.
• The // DELETEME is attached to a console.log used for debugging, meaning that log is not meant to stay in the final code (maybe it was helping the developer verify things during development).

If the developer moves on and nobody revisits this code, a year from now it’ll still have that slow loop, the bug with null inputs, and an unnecessary log slowing things down or cluttering output. Each of those comments was an alert that refactoring or fixes were needed, yet nothing happened – that’s how you accumulate technical debt. Over time, other developers might add more code around it, making it even harder to fix without breaking something. This is why a code file full of TODOs and FIXMEs can be frustrating to work with. It’s like inheriting someone’s Never-Ending TODO list.

The meme’s podium joke is really about shared developer experience. We’ve all left a //TODO or //FIXME at some point, promising ourselves we’ll come back later. Many of us have even seen or written a desperate //DELETEME for code that was meant to be temporary. The humor comes from admitting that these “notes to self” often end up being forgotten. So among developers, we laugh that the worst bad habit (“winner”) is knowingly leaving junk in the code – hence //DELETEME gets the gold medal. It’s a lighthearted reminder to all of us: next time, instead of just commenting “delete me,” maybe actually delete the code (you have version control if you need it back!). Or if you write “FIXME,” try to schedule time to really fix it. Otherwise, you might end up with a project that’s essentially held together by to-do notes and duct tape, and nobody wants to win first place in that contest!

Level 3: Procrastination Podium

At the pinnacle of this Technical Debt Olympics stands the infamous //DELETEME comment, hoisting the gold trophy for ultimate code neglect. The meme’s podium ranks code comment atrocities: //TODO in third place, //FIXME in second, and the reigning champion //DELETEME as the worst thing developers do in code. It’s a tongue-in-cheek way to highlight a spectrum of code comment abuse that leads to serious TechDebt and CodeQuality issues over time. Why is //DELETEME deemed the “winner” of this shameful contest? Because it’s essentially the developer admitting “this code should be gone” and then not removing it. It’s like winning first place in an anti-quality competition: proudly the worst.

Let’s unpack the podium: Third-place //TODO comments are the mildest form of technical debt. A //TODO is a promise of future work – a developer saying “I didn’t finish this, I’ll do it later.” On its own, a //TODO is a common CodeComment used during crunch time or prototyping: e.g., “//TODO: improve error handling”. It signals an incomplete task, a reminder that something in the code isn’t fully baked. One or two of these might be harmless, but when an entire codebase is peppered with //TODO markers from months or years ago, it’s a red flag. It means features were left half-done or improvements postponed indefinitely. In the industry, it’s not unusual to find a //TODO that’s so old the context is lost (“TODO: refactor this – 2015” 😬). Each forgotten //TODO is a little IOU contributing to the TechnicalDebt ledger, silently accruing interest.

Second-place //FIXME is a step up in severity. This tag says “I know this code is broken or wrong, but I’m shipping it anyway (and I or someone should fix it later).” It’s a blatant admission of a bug or flaw. For example, “//FIXME: this returns wrong values for negative inputs” might sit above a sloppy piece of logic. Leaving a //FIXME in production code is essentially knowingly injecting a CodeSmell – it’s like taping a “Kick Me” sign on your code for future developers. Why would anyone do this? Often because of deadlines, or because the fix is non-trivial and time is short. Experienced devs have all had moments at 3 AM where slapping a quick hack with a //FIXME comment felt acceptable to keep systems running. But each //FIXME is a ticking time bomb. It represents developer frustration deferred: eventually, an on-call engineer at midnight will curse that //FIXME when it blows up, saying “They knew this was an issue and left it!” In terms of technical debt “interest,” //FIXME incurs a higher rate – what starts as a minor known bug can snowball into major failures or quality issues if not addressed. In fact, many CodeQuality tools (linters, static analyzers like SonarQube) will specifically flag TODO and FIXME comments to make sure they aren’t forgotten. Some teams even forbid merging code with FIXME comments, treating them as RefactoringNeeded before release.

Now, the gold medalist //DELETEME: this one is the dark legend of code comments. It literally means “I should delete this code.” It often appears when a developer has disabled a chunk of code or left a temporary snippet, marked with //DELETEME as if to say “This is garbage or workaround code – remove it once we’re safe.” The big sin here is that the code doesn’t belong at all, even more so than a known bug. Maybe it’s obsolete logic that got replaced but wasn’t fully removed, or some debug printing left in production because of paranoia that we might need it later. Leaving a //DELETEME in the code is like leaving a dead tree branch hanging over a power line – it’s obvious to everyone it should be taken down, yet there it is, waiting to cause trouble. It’s considered worse than //FIXME or //TODO because it’s not just something undone or broken; it’s something unnecessary or harmful left deliberately. From a maintenance perspective, commented-out or deprecated code marked “delete me” is pure clutter: future maintainers will scratch their heads thinking, “Why wasn’t this removed? Does it still serve a purpose? Is it safe to delete now or is something subtly relying on it?” This uncertainty can actually impede refactoring efforts – people become afraid to remove the supposedly “to-be-deleted” code, especially if it’s been there for ages and nobody remembers the context. I’ve seen ancient modules where a //DELETEME comment fossilized in source control for years, basically becoming a permanent monument of procrastination. In the CodeQuality hall of shame, that’s gold-medal material. 🏆

The humor in the meme comes from treating these negative practices as competitors in an Olympic race – it’s an ironic celebration of bad habits. Seasoned devs chuckle (or groan) because we’ve all encountered these in real projects. The image literally shows people on a podium with trophies labeled //TODO, //FIXME, //DELETEME, as if developers are winning at creating technical debt. It resonates because it’s a shared truth: what starts as a quick fix or a “note to self” can turn into long-term TechnicalDebt if ignored. The meme exaggerates it to say, among all the shortcuts we take, leaving code that you admit should be deleted is the absolute worst. In a darkly comic way, it acknowledges that DeveloperHumor often comes from a place of DeveloperFrustration. We joke about the “Technical Debt Olympics” because sometimes laughing at our own messy code is the only way to cope with it. After all, if procrastination were a sport, developers leaving //DELETEME comments would take home the gold every time.