Call Me Scooby Because I Can't Doo This PR Anymore
Why is this CodeReviews meme funny?
Level 1: No More Changes
Imagine you’re doing your homework, and you show it to your teacher to check. The teacher says, “It’s good, but you need to fix a couple of things.” So you go back and fix those things. Then you show it again, and now the teacher finds a few more tiny issues: “Actually, change this word and add a sentence here.” You do that, a bit tired but okay. Now, think about this happening over and over, 13 times! By the thirteenth time, you’d probably feel super frustrated and tired, right? You might even want to throw your hands up and say, “I don’t want to do this anymore!”
That’s exactly what’s going on in this picture. The programmer (represented by the funny dog) has been asked to change their work so many times that they just can’t take it anymore. They’re so tired that they make a silly joke: they say “Call me Scooby because I can’t Doo this anymore.” Scooby-Doo is a cartoon dog who’s known for the word “Doo” in his name, which sounds like “do.” So the programmer is basically saying, “I can’t do this anymore,” in a playful way. It’s like if you were so done with homework that you said, “I’m not a student, I’m Scooby-Doo now, and Scooby-Doo can’t do this homework anymore!” It’s a goofy way to express being completely exhausted. The reason it’s funny is because it mixes a very relatable feeling (being worn out from doing something over and over) with a cartoon pun. Even if you don’t know about programming or pull requests, you can understand that the poor dog has had enough of whatever is going on. Everyone has felt that “I can’t do this anymore” feeling at some point – like cleaning your room for the tenth time or practicing a song on the piano endlessly. The meme just uses Scooby-Doo to say it in a lighthearted, joking way.
Level 2: Review Roundabout
Let’s break down what’s happening in this meme in simpler terms. In software teams, when you finish working on some code, you don’t just put it directly into the main application. You usually open a pull request (often abbreviated PR) – which is basically a request asking, "Hey, I wrote this code, can you review it and pull it into the project?" This triggers a code review, where other developers look at your changes and provide feedback. They might point out mistakes, suggest better ways to write something, or ask for clarifications. It’s like turning in an essay and having a peer or teacher mark it up with red ink – but in coding, you get to revise the code and try again. A pull request isn’t considered complete until reviewers are satisfied and approve it (often with a comment like “LGTM”, meaning Looks Good To Me).
Now, one round of feedback and revisions is normal – even two or three rounds for a tricky change is fine. But this meme jokes about a 13th round of changes. That’s a lot. Imagine your teacher asking you to redo an assignment 13 times – by the end, you’d be pretty upset, right? That’s exactly the feeling here. Every time the developer thought they were done, a reviewer came back with “Actually, please change this one more thing…” It’s a repeated review cycle that just won’t end. Going through 13 revisions on a single pull request means the poor developer has probably been stuck on this task far longer than they ever expected. Each cycle probably involved re-running tests, waiting for continuous integration (automated checks) to pass, then having someone find yet another tiny issue. It’s a roundabout that keeps looping instead of letting the developer move on.
The top text of the meme sets that scene: “When someone asks for more changes on your pull request for the 13th time.” You can almost hear the groan in that statement. It’s practically saying, “Seriously? I have to fix things again? We’ve done this 12 times already!” This is a big developer reality in team projects – sometimes the review process drags out and you feel stuck. It highlights a Developer Experience (DX) problem: the longer this goes on, the more it drains the person writing the code. Sure, the goal is to make the code better, but after so many rounds, it’s hard to stay enthusiastic. Developer productivity can drop because the coder is spending time on very minor tweaks rather than building new features or fixing new bugs. And emotionally, it’s exhausting; you start to doubt your work or just feel frustrated with the whole process (DeveloperFrustration is real!).
Now let’s talk about the punch line: “Call me Scooby because I can’t Doo this anymore.” If you read that out loud, it sounds like, “Call me Scooby because I can’t do this anymore.” It’s a pun. Scooby-Doo is a famous cartoon dog (from the show Scooby-Doo where a group of friends and their Great Dane Scooby solve mysteries). The name “Scooby-Doo” has that “Doo” at the end, which is just a fun spelling of the word “do.” In the cartoon, Scooby’s often scared or overwhelmed, saying things in his goofy dog voice like “Ruh-roh!” (his way of saying “uh oh”). The meme makes a joke that the developer has reached such a level of burnout that they’re basically identifying with Scooby-Doo – a character who usually runs away when things get too scary or difficult. “I can’t do this anymore” is a phrase you say when you’re at your breaking point, ready to give up. By spelling “do” as “Doo,” the meme ties it back to Scooby. It’s a playful way to say “I’m done with this; I just can’t continue,” while also referencing a beloved cartoon from many people’s childhoods.
The image of the dog is also part of the joke. The dog pictured is a Shiba Inu, famously known from the “Doge” meme. The Doge meme shows a Shiba Inu dog making a funny face, usually surrounded by multicolored Comic Sans text like “so wow,” “much amaze,” etc. It’s an internet culture icon signifying silliness and sarcasm. Here, the Shiba Inu is wearing Scooby-Doo’s signature blue-green collar with the diamond-shaped tag (just like Scooby wears in the cartoons). So the creator of this meme mixed two memes together: Doge (the internet doge dog) and Scooby-Doo (the cartoon dog). The result is inherently silly – a Shiba Inu pretending to be Scooby-Doo. The text “Call me Scooby” above the dog’s head shows that the dog (representing the developer) is announcing their new identity as Scooby. And the text below “because I can’t Doo this anymore” completes the thought. Visually, it’s funny because the dog has a bit of a resigned, blank expression – the kind of face that says “I give up” in the most deadpan way.
For someone new to software development, it’s useful to know that code reviews (and thus pull requests) are generally positive practices. Getting feedback is how we catch mistakes early and learn from teammates. But this meme is poking fun at when that good practice goes slightly off the rails. Instead of a quick back-and-forth, it’s become a marathon. By the 13th request for changes, the developer probably feels like they’re never going to get this code approved. The phrase “I can’t do this anymore” really encapsulates that feeling of being worn out. It’s definitely a relatable dev experience for anyone who’s had a tough code review. And even if you haven’t experienced exactly 13 rounds of revisions, it exaggerates a feeling most people understand: doing something over and over to the point where you just don’t want to continue.
So, in simpler terms: The meme is about a programmer who is extremely tired of fixing their code because the reviewer keeps asking for more changes, again and again. They joke that you might as well call them “Scooby” now, referring to Scooby-Doo, because they "can't Doo (do) this anymore." It’s a fun way to say “I’m exhausted and done” using a pun and a goofy dog picture. It highlights the frustration of too many review cycles in a way that’s meant to make fellow developers laugh and say, “Oh man, I’ve been there!”
Level 3: Pull Request Purgatory
When someone asks for more changes on your pull request for the 13th time
That caption sets the stage: the developer has been through twelve rounds of making changes, addressing feedback, and re-submitting their code, only to have the reviewer come back yet again with "Could you tweak this just a little more?" At this point, our poor developer is stuck in Pull Request purgatory – a state of limbo where the code isn’t bad enough to outright reject, but it’s never deemed good enough to approve. This is a classic CodeReview pain point: the endless cycle of revisions. It’s a scenario many senior engineers know all too well, often accompanied by an eye-roll and a heavy sigh. After enough rounds, the DeveloperExperience (DX) degrades from constructive collaboration into a soul-draining slog. The meme captures this perfectly with a mix of humor and despair.
The image itself is doing a lot of comedic heavy lifting. We see the iconic Doge (that Shiba Inu internet meme dog with the mischievous grin) dressed up in Scooby-Doo’s turquoise collar and tag. This mashup of meme cultures (modern Doge + classic Scooby-Doo) immediately signals that something absurd and humorous is happening. Doge’s face is famously associated with inner monologues of bemusement and weariness ("much tired, very done" vibes), which fits the developer’s mental state on the 13th review iteration. By putting Doge in Scooby’s role, the meme draws a parallel between a developer exhausted by code reviews and a cartoon dog who’s had enough of chasing spooky villains. It’s an absurd comparison that lands because at round 13 of a review, you feel a bit absurd yourself – like, am I really still dealing with this?
Now, the text plastered over the image delivers the punch line: “Call me Scooby because I can’t Doo this anymore.” This is a clever Scooby-Doo pun. Scooby-Doo’s name ends with "Doo," which sounds exactly like the word “do.” By saying "I can’t Doo this anymore," the developer is really saying "I can’t do this anymore" – i.e., I’m completely exhausted and done with these changes. It's a playful way to express serious fatigue. And the setup "Call me Scooby" implies I have turned into Scooby-Doo, because only a hapless cartoon dog could be as fed up (or as comically tragic) as I am right now. In other words, I've been reduced to a Scooby-level of helplessness. It’s like saying “I give up on being a normal programmer, I’m a cartoon character now because this process stopped making sense 5 revisions ago.”
For seasoned developers, this scenario is painfully relatable. Code reviews are a critical part of maintaining quality – they catch bugs, enforce best practices, and share knowledge. But there’s an unspoken tipping point where the process can go from helpful to hindering. By the time you’re addressing the 13th round of comments, you’ve probably fixed the major issues back in round 3 or 4. Everything after that might be ultra-minor: changing variable names, rewording comments, adjusting indentation, or other nitpicks. We have a term for this kind of overzealous scrutiny: bikeshedding (from Parkinson’s Law of Triviality), where people spend excessive time on trivial details. In a healthy review cycle, reviewers focus on important correctness and design issues. But if you end up in a 13-round saga, odds are you’ve entered bikeshedding territory – perhaps one reviewer keeps insisting on their personal coding style preferences or there are conflicting opinions among multiple reviewers that send you in circles. The meme is essentially screaming: “This is no longer about code quality, this is torture!”
From an organizational perspective, a pull request dragging through countless review cycles is a warning sign. It hurts Developer Productivity because instead of moving on to the next task, a developer is tied up revisiting the same code over and over. Morale takes a hit with every "Just one more change..." comment. The phrase "well-intentioned quality gate" definitely applies here: code reviews are meant as a gate to ensure quality, but when that gate gets stuck half-closed, nobody gets through and people start getting frustrated. Developers often quip that a pull request at this stage feels less like a collaboration and more like an endurance test. We've all seen PR comments that make us mutter, "Really? We're still on this?"
Imagine hitting that “Request Changes” button for the 13th time – even the reviewer might be fatigued at this point. (There’s a hint of irony: by round 13, reviewer fatigue is real too, yet somehow they mustered the energy to ask for another change!). In real-life scenarios, if a code review requires so many iterations, teams might call for a face-to-face chat or a Zoom meeting to sort things out quickly. It’s often more efficient to talk through the bigger issues rather than drip-feed comments one by one. The meme’s developer, however, seems to be dealing with a process that just won’t shift out of first gear. Hence the exasperation: turning to gallows humor (the Scooby-Doo reference) is a coping mechanism. If we don’t laugh, we might cry – and developer humor like this meme is a way to collectively laugh at a frustrating reality.
Let’s also appreciate the number 13 here. It’s famously an unlucky number, and indeed a 13th round of review changes feels cursed. Many senior devs have war stories: “I once had a PR go through double-digit revisions” – it’s always told with a mix of pride and horror. By invoking the 13th time specifically, the meme taps into that folklore of engineering absurdity. It’s like saying, “This code review is officially in nightmare territory.” At that point, the original excitement for the feature or bugfix you were working on has long evaporated. The Developer Frustration is real – you’re not improving the code anymore, you’re appeasing the process. The meme shows the author at that breaking point: if you ask for one more change, I’m not even a developer writing code now, I’m Scooby-Doo, bumbling through an overlong cartoon of a code review.
In summary, the humor here comes from how true to life it feels. It’s absurd, yes, but only slightly more absurd than some real experiences in corporate development. The combination of the Doge visual, the Scooby-Doo pun, and the painfully exact “13th time” scenario hits multiple layers of comedic reference. Experienced devs chuckle (or groan) because they’ve been in that pull request purgatory, negotiating yet another round of the review process and thinking “I can’t do this anymore.” The meme takes that exact thought and gives it a memorable, funny packaging – a tired cartoon dog who has simply had enough.
Level 4: The Halting Problem of Code Reviews
In theoretical computer science, the Halting Problem proves there's no general algorithm to decide if a program will ever finish running. In a darkly humorous twist, an endless code review feels just like an undecidable loop. Every time the reviewer demands another tweak, it's like another iteration with no guaranteed termination. By the 13th round of requested changes, this pull request has become the coding equivalent of a recursive function missing a base case. You can't predict if or when it will finally end – Alan Turing himself would smirk at the similarity. Is there an eventual merge or are we stuck in review limbo forever? The meme exaggerates this by invoking Scooby-Doo, as if to say: solving this PR is as mythical (and never-ending) as one of Scooby’s ghost hunts.
To put it in algorithmic terms, each review cycle is an iteration refining the code. Ideally this process converges toward approval, much like an iterative algorithm approaching a solution. But here we see the nightmare scenario: convergence so slow (or non-existent) that it might as well be an infinite loop. There's a whiff of Zeno’s Paradox – every review gets you halfway closer to "perfect code" but you never quite arrive. Formally, we might say the marginal utility of each additional change is diminishing; the first few review cycles catch real bugs or design issues, but by round 13, you're likely fixing minor naming conventions or adding a comma to a comment. The process approaches an asymptote of perfection that never truly reaches 100%, because in code there's always something more to improve. The cost (in time and mental energy) grows unbounded while the benefit shrinks – a classic case of diminishing returns in action.
Consider a pseudocode representation of this scenario:
while (!code.isApproved()) {
reviewer.requestChanges(); // "Just one more tiny fix..."
dev.implementChanges(); // Developer obediently makes the change
if (dev.isExhausted()) break; // Halting condition: dev can't Doo it anymore
}
This loop might remind you of a non-terminating program. There's no guaranteed break condition since a reviewer can always say "LGTM, but just one more thing...". In a theoretical sense, deciding if the review will ever conclude is as hard as solving the Halting Problem – you only know it halts when it actually halts. Until then, each requestChanges() could spawn yet another cycle. It’s a tongue-in-cheek analogy, of course: code reviews should terminate, but it sure doesn’t feel that way when you're on round 13. The developer’s dramatic Scooby-Doo reference ("I can’t Doo this anymore") is like an emergency break out of the loop, a cry for mercy when the formal process offers no escape. Even the most robust coding practices don’t specify what to do when everyone is just done with the process – at some point, the human factor (fatigue, exasperation) becomes the real halting condition. In essence, the meme is poking fun at how a well-intentioned quality assurance loop can morph into a potentially infinite process, one that no amount of algorithms or formal methods can easily resolve because it’s ultimately governed by human judgment (and human stubbornness).
Description
A meme with top text 'When someone asks for more changes on your pull request for the 13th time' above a Doge/Shiba Inu dog wearing Scooby-Doo's collar with a tag reading 'CD'. The dog has a sad, exhausted expression. Text overlaid reads 'Call me Scooby because I can't Doo this anymore.' The pun combines the Scooby-Doo character name with expressing burnout from endless code review change requests. The collar tag 'CD' could also reference CI/CD
Comments
11Comment deleted
After the 13th round of PR changes, the 'Request Changes' button should auto-rename to 'Request Therapy' and the reviewer's next comment should trigger an HR ticket instead
After thirteen review rounds, my diff header is starting to look like a blockchain - append-only, immutable, and no one actually understands what’s in it anymore
After 15 years in the industry, I've learned that the thirteenth PR review comment is when reviewers start suggesting we rewrite it in Rust, add blockchain for audit trails, and somehow make it both eventually consistent AND strongly consistent - because apparently Schrödinger's CAP theorem is now a design pattern
After the 13th round of PR changes, you realize the real technical debt isn't in the codebase - it's the psychological debt accumulated from explaining why your variable naming convention is perfectly cromulent while your reviewer insists on bikeshedding every semicolon. At this point, you're not refactoring code; you're refactoring your will to live, one 'nit:' comment at a time
By the 13th review cycle, we’ve pivoted from Continuous Delivery to Comments‑Driven development - DORA calls it lead time, I call it Doo‑not‑merge
13 PR revisions? That's not review - it's a denial-of-service attack on your merge hopes
After the 13th round of “nit:” comments, my PR has Raft safety but zero liveness - still waiting for an LGTM quorum
Just do it from the first time already Comment deleted
Call me Scooby because I can't do watch same pr for the 14th time after junior dev fixed one of 16 correcting comments AND AGAIN THINKS ALL THE REST COULD BE IGNORED Comment deleted
https://t.me/dev_meme/4829 Comment deleted
I'm going to crop this and use it on a daily basis Comment deleted