Reporting my messy pull request as garbage using Facebook options

Level 1: Messy Room Moment

Imagine your teacher asked you to show your bedroom to the whole class, but your toys and clothes are thrown everywhere and there’s a half-eaten sandwich on the floor. You’d feel pretty embarrassed, right? You might even joke, “Ugh, this looks so bad I want to hide it!” That’s exactly what’s happening here, but with a programmer’s code. The picture shows a big mess (like a dirty, junk-filled room but outside), and the programmer is saying, “This mess is like the thing I made.” They’re using a pretend Facebook button that normally lets you complain about a bad or embarrassing picture. By clicking “My PR is in this photo and I don’t like it,” the programmer is basically laughing at themselves and saying their code turned out as messy as a pile of garbage, and they wish they could make it disappear. It’s a funny way for grown-up engineers to admit, “Oops, I made a mess!” in a language everyone can understand.

Level 2: Messy Code Blues

If you’re a newer developer, let’s break down why having “my PR” associated with a literal pile of garbage is both humorous and cringingly real. First, some terminology:

• A Pull Request (PR) is a way to ask that your code changes be merged into the main codebase (like on GitHub or GitLab). It’s basically saying, “Hey team, I’ve got some new code. Can you review it and add it to the project?” It’s a core part of modern version control collaboration using tools like Git.
• Code Review is the process where other developers examine that PR. They look for bugs, check if the code follows standards, and verify that it works. Think of it as proofreading and testing someone’s essay, but the “essay” is code that might run your app or website.
• Code Quality refers to how well-written and maintainable the code is. High-quality code is clean, understandable, and efficient. Low-quality code might work, but it’s confusing, fragile, or full of hacks that make other developers groan.
• Spaghetti code is a nickname for code that’s all tangled up and twisty, like a bowl of spaghetti. This happens when the flow of a program jumps all over the place (for example, lots of goto statements in old languages, or deeply nested logic in modern code). It’s hard to follow, hard to maintain, and easy to break – just like it’s hard to pull one strand of spaghetti out of a knot without moving others.
• Technical debt is a metaphor comparing messy or quick-fix code to financial debt. When you write something in a hurry just to solve an immediate problem, it’s like taking on debt – you saved time now, but you “owe” a cleanup later. If you don’t pay back that debt by refactoring (cleaning up the code), interest accumulates: the code gets even harder to change or fix in the future.
• Developer self-deprecation is when programmers jokingly put themselves down. In this context, the person who made the PR is making fun of how bad their own code turned out. It’s a coping mechanism – if you laugh at your mistake first, it hurts less when others point it out!

Now, the meme itself: The Facebook report dialog parody at the bottom is designed to look just like a menu you’d see when flagging a post on social media. Websites like Facebook allow you to report content for reasons like “It’s spam” or “It’s inappropriate.” One specific option on Facebook is “I’m in this photo and I don’t like it,” used when a picture of you (maybe doing something embarrassing) is posted without your okay. The meme replaces that with “My PR is in this photo and I don’t like it.” Why? It’s implying the coder sees that huge trash pile photo and thinks, “Yikes, that’s basically my code shown to everyone, and I wish it wasn’t!” It’s a perfect mix of tech and everyday life references – even if you haven’t reported a photo on Facebook, you get the idea of wanting to hide something embarrassing that’s connected to you.

The garbage pile visual metaphor here is straightforward and effective. We often compare bad, disorganized code to trash. If you’ve ever looked at a confusing program and groaned, “Who wrote this junk?”, you know the feeling. Here the author of the code is admitting “I wrote junk.” The image literally shows a pile of refuse dumped by the roadside. It’s not in a bin; stuff is strewn everywhere; it’s an eyesore – just like a disorganized code diff (the set of changes in the PR) would appear to a reviewer. Imagine a PR where files have changes all over the place: random print/debug statements left in, inconsistent naming of variables, functions that are way too long, maybe some dead code (unused code) lying around like that broken couch that nobody carried off. The meme exaggerates this to make a point: the PR is so awful in the author’s eyes that it belongs in a dumpster, not in the codebase.

Seeing the option “My PR is in this photo and I don’t like it” already checked is basically the developer preemptively roasting their own work. It’s like saying, “This picture of a mess is exactly what my code is, and I’m the first to admit it.” Developers often feel a mix of pride and embarrassment about their code. We’re proud when it works, but embarrassed if it’s not pretty under the hood. Especially in a team setting, nobody wants to be the one who submits the PR that becomes an inside joke. This meme taps into that pull request embarrassment. It’s normal for a new dev to worry, “What if my code isn’t good enough and everyone thinks I’m clueless?” The truth is, even the pros write ugly code sometimes. The difference is, seniors know it’s ugly and can joke about it – like this meme – because it’s practically a rite of passage. At some point, you will write something kludgy (a clumsy quick-fix solution) and a colleague will see it. Laughing it off and then fixing it is healthier than pretending it never happened.

Also, notice the other options in the fake dialog, which match how we might criticize a bad PR:

• “It’s annoying or not interesting” might equate to code that’s a pain to review or that doesn’t add anything cool – maybe a PR full of minor, nitpicky changes that feel noisy and trivial.
• “I think it shouldn’t be on Facebook” in our context means “this shouldn’t be in our repo.” It’s the feeling that this code is so off-base or poor quality that it doesn’t belong in the project at all – maybe it solves the problem the wrong way or violates the team’s standards.
• “It’s spam” is like saying the PR is just noise. For instance, imagine a PR that accidentally included thousands of irrelevant changes because of a misconfigured auto-formatting tool – all the real logic is buried in that noise, effectively spamming the reviewers. Or a PR that does something and then undoes it over and over in multiple commits. Reviewers sigh when they see those, because separating useful changes from spammy ones is a lot of extra work.

For a junior developer, it’s important to know that these feelings are common. When your Git commits turn into a chaotic PR, it doesn’t mean you’re a bad programmer; it might just mean you were moving fast or learning as you went. What matters is how you handle it afterward. Experienced teams will often say, “Let’s clean it up” rather than “Who wrote this trash?”. And many of us cope with the stress of exposing our messy work through humor – exactly like this meme does. We’ve all been there, embarrassed by something we coded. The best practice is to break up large, messy code changes into smaller pieces and refactor step by step. But when you can’t, at least you can jokingly click “report” on your own PR and share a laugh, then get down to the real work of tidying that code.

Level 3: Landfill of Technical Debt

Cue the facepalm: every experienced engineer has opened a Pull Request (PR) that felt like dumping a trash can onto their team's desk. This meme nails that all-too-familiar code review shame. The top half shows a literal junk heap—broken couch, scattered bags, and debris—visually screaming “hot mess.” The bottom half cleverly imitates Facebook’s content report dialog with the option “My PR is in this photo and I don’t like it” selected. Why is this hilarious? Because it’s a perfect collision of developer reality and social media culture: we’ve all had code so embarrassingly messy we wish we could report it as garbage and have it magically removed from the repository.

In a senior developer’s world, this scenario is the embodiment of technical debt and spaghetti code coming home to roost. The landfill in the photo isn’t just random trash—it’s a metaphor for a PR jam-packed with haphazard fixes, copy-pasted blocks, and TODO comments breeding like rats. That broken couch? That’s the half-implemented feature you promised to polish later but never did. The scattered trash represents every quick-and-dirty patch thrown in under deadline pressure. Over time, these “just ship it” decisions accumulate into a big ball of mud – an infamous anti-pattern where a codebase lacks clear structure, much like a garbage pile with no order. When it’s finally time for a code review, the author of such a PR is painfully aware of its state. Checking the “My PR is in this photo and I don’t like it” box is a tongue-in-cheek way of saying, “Yep, that hideous heap you see? That’s my code, and I hate that it looks like that.”

This humor resonates with veteran developers because it satirizes the emotional rollercoaster of code reviews. First comes optimism (“It works, I think we’re good to open a PR!”), quickly replaced by dread (“Oh no, they’re going to see my shortcuts”). It’s common to see a PR description start with an apology or a self-deprecating remark – a reflex to soften the blow for reviewers facing a rough diff. In extreme cases, you might have considered closing the PR and refactoring first, but business pressures often don’t allow that luxury. Code quality often takes a back seat to shipping on time, and engineers accumulate technical debt like candy wrappers in a cubicle: one by one it’s not bad, but eventually someone notices the overflowing bin.

The meme’s use of the Facebook-style report dialog is more than just a funny visual mashup – it highlights how devs sometimes feel about their own code: that it’s offensive content. Facebook’s real report option “I’m in this photo and I don’t like it” is normally about flagging embarrassing images of oneself. Here it’s brilliantly repurposed to flag embarrassing code we wrote. It’s a wink to developers: reviewing your own diff can feel like looking at an unflattering candid photo – “Is that really what I look like… what my code looks like?” The other options in the dialog (“annoying or not interesting,” “shouldn’t be on Facebook,” “spam”) add extra layers of industry inside-joke:

• “It’s annoying or not interesting” – That’s basically how a weary reviewer feels about a noisy, convoluted PR that’s hard to follow. It’s annoying to review and certainly not interesting to decipher thousand-line diffs filled with hacks.
• “I think it shouldn’t be on Facebook” – Translate: “This code shouldn’t be on GitHub/GitLab.” In other words, “This code has no business being in our codebase at all.” Every senior dev has encountered code so bad they think, “We should rewrite this from scratch rather than merge.”
• “It’s spam.” – In a coding context, a spammy PR might be one that triggers endless notifications or is full of unrelated changes (like reformatting noise). But mostly, calling your own PR “spam” is the ultimate self-own: “Don’t bother reading this noise.”

The version control workflow itself contributes to the meme’s relatability. In modern Git-based collaboration, opening a PR is akin to exposing your code for all to scrutinize. There’s an implicit pressure to make it clean and polished. Yet in reality, especially on crunch timelines, PRs often include weird commit histories, half-baked functions, and commit messages like ~~WIP~~ final fix – sorry. A senior engineer knows that a PR isn’t just code; it’s a narrative of how that code came to be. And an ugly narrative (say, a commit history with multiple reverts, or files added then removed mid-stream) tells reviewers exactly how chaotic the development process was. It’s like leaving evidence of every wrong turn and hack – no wonder the author feels exposed.

The industry has developed practices to avoid this kind of pull request embarrassment. We preach writing smaller PRs, adding thorough tests, doing pair programming, and documenting changes to keep quality high. But the joke is that even with all that preaching, reality often intervenes. Tight deadlines, unclear requirements, or sudden pivots can force even meticulous coders to produce “garbage” code in the short term. There’s a common saying in engineering teams: “We’ll refactor it in the next sprint.” Spoiler: that next sprint often never comes, and the “temporary” garbage becomes permanent. This meme wryly acknowledges that gap between ideal and reality. We chuckle because either we’ve written such a PR or had to review one. It’s funny and painful remembering that time you opened a PR at 3 AM, bleary-eyed, thinking “please don’t judge me by this code,” effectively wishing there was a “report my own PR as trash” button to save you from the morning’s code review comments.