Skip to content
DevMeme
572 of 7435
The Agony of Waiting for a Code Review
CodeReviews Post #655, on Sep 9, 2019 in TG

The Agony of Waiting for a Code Review

Why is this CodeReviews meme funny?

Level 1: Watching Paint Dry

Imagine you’ve just finished a big school project and you need your teacher or a friend to check it before you can turn it in. You’re super ready to move on to something fun, but you’re not allowed to proceed until they say, “Looks good!” Now, your friend or teacher is busy, so you’re just… waiting. You wander from the kitchen to the living room, peek out the window, then back to your room, just waiting and waiting. It feels like forever, and it’s soooo boring. This meme is about that exact feeling, but for a programmer at work. It’s like when a video game or a cartoon is stuck on a loading screen with the little circle spinning and nothing else happening – you sit there, maybe start humming or tapping your foot, wondering if it will ever finish.

The guy in the picture is basically doing that: walking around his house, looking at random things, because he’s already done his work but has to wait for someone else. It’s a funny way to say “Waiting for this is making time stand still.” It’s the same energy as waiting for paint to dry on the wall or water to boil – you can’t rush it, and watching it just makes it feel even slower. The humor comes from how perfectly the pictures show that empty, slightly desperate waiting feeling. He looks a bit lost, right? We laugh because we’ve all been there in one way or another – when you’re ready to go, but stuck waiting on somebody else. In simple terms, the meme jokes about being bored out of your mind while you wait, turning that frustration into something we can smirk at.

Level 2: Idle in the PR Queue

Let’s break down what’s happening in this meme in simpler terms. The text says, “Me waiting for someone to review my code.” This is a common scenario in software teams. After a programmer finishes some code changes, they usually open a pull request (PR) – basically a request for their team to look at the changes and approve them to be merged into the main code. Code review is the process where another developer checks your work: they look for bugs, suggest improvements, and make sure the code fits the project standards. It’s like doing homework and then asking a friend or teacher to double-check it.

However, code reviews are often asynchronous, meaning you send out your code for review and then you have to wait for someone to respond when they have time. It’s not like a live conversation or immediate approval; it’s more like sending an email and waiting for a reply. This can lead to a slow feedback loop – you might wait hours or even days to get comments or approval on your code. During that waiting time, you might be stuck. In many teams, you can’t merge (finalize) your code changes until someone else from the team signs off. So you’re essentially on hold. This waiting period is what the meme is humorously depicting.

In the images, the same man is shown standing around in different parts of a house with nothing to do. That’s a dramatization of idle time. He’s not coding, not getting feedback, just waiting. In one frame he’s literally hands in pockets in the kitchen, in another he’s staring at a painting, then looking at a cabinet of teacups, and finally checking himself out in a mirror. It’s a funny way to show that feeling of idle waiting – when you’ve finished your work but can’t proceed further. Every developer has had that moment of “Well, I’ve put up my code for review… now what do I do?” You might start browsing the internet, or go make a coffee, or just sit and spin in your chair because you can’t progress until Bob or Alice from your team looks at your code changes.

This waiting_for_code_review state is a bit frustrating because it feels like wasted time. In a fast-paced development workflow, suddenly you’re forced to slow down or stop. It’s a common workflow disruption in the modern development process. The phrase “infinite loading spinner” refers to the little spinning icon you see when something is loading but taking forever – like when a web page just keeps loading and never finishes. The meme compares waiting for code review to that never-ending loading sign. You, as the developer, feel like you’re stuck watching that spinner spin. The man standing around is basically acting out what that spinner feels like in human form.

Some important terms here: Version control is the system (like Git, used via platforms like GitHub or GitLab) that developers use to manage code changes. When they commit changes and push them, they often open a pull request to propose merging those changes to the main codebase. The pull_request_queue is just a way of saying there are multiple PRs waiting for review. If your team is busy or has many incoming PRs, yours might sit in the queue for a while. This leads to idle_time_costs – basically lost productivity because you’re just waiting. Good teams try to minimize this by reviewing promptly or by having other tasks you can do, but it’s not always perfect.

The meme falls under DeveloperHumor because it exaggerates a real feeling in a funny way. It’s immediately relatable to many developers (a classic RelatableDevExperience moment) because waiting for a code review is so common. People might chuckle at this because they remember pacing around or constantly checking their notifications hoping that a teammate finally reviewed their code. It also hints at a slight frustration with process overhead: code reviews are a process meant to improve code quality, but sometimes the process itself becomes a bottleneck. That’s the joke – we introduced a process to help us, yet here we are stuck in that process, just standing around.

In simpler words, the meme is saying: “I’ve done my part, and now I’m just standing here doing nothing, waiting for you to do yours.” It highlights a little inefficiency in how teams work. The man in the meme isn’t actually doing any work in those panels – he’s literally just waiting. And as any developer knows, waiting for someone else to take action can be one of the most frustrating things, because it’s out of your control. You can’t force your teammate to review faster (at least not without annoying them). You’re at the mercy of someone else’s schedule. So this meme playfully jabs at that scenario. It’s like, “Hello… anyone? Could someone please review my code so I can move on?” said in the form of a funny image.

Overall, at this level, the key point is: code reviews are good, but waiting for them is annoying. The meme uses a series of images of a guy doing nothing to drive home just how boring and unproductive that wait feels. If you’re a newer developer, now you know – this is a normal part of the job in many places! You finish something, and sometimes you’ll be in limbo until a colleague has time to give you a thumbs-up. It’s all part of asynchronous teamwork. And yes, it can genuinely feel like watching a loading icon spin endlessly, which is both funny and a little sad, as the meme humorously points out.

Level 3: Pull Request Purgatory

On a more practical level, this meme lands squarely in CodeReviewPainPoints territory – it’s painfully relatable for any developer who’s been stuck in pull request purgatory. We have all been that engineer who finishes a task, opens a pull request (PR), and then... nothing happens for ages. The code is out for review in an asynchronous collaboration system, and you’re left in limbo. The collage of the same man standing around different parts of the house perfectly captures the restless idle time that ensues. Panel by panel, he’s essentially killing time: first loitering in the kitchen, then glancing at a painting, then examining fine china in a cabinet, and finally staring at himself in the mirror as if to say, “What am I doing with my life right now?” It’s developer humor drawn from real experience – an exaggeration of how we wander around the office (or our home office) when blocked by a slow review.

Why is this funny? Because it’s true. In many teams, getting a timely code review can feel harder than solving the actual coding problem. A supposed agile workflow can grind to a halt due to process overhead: perhaps the designated reviewer is swamped with other tasks, in endless meetings, or out sick, leaving your PR languishing. It’s a relatable dev experience to see your work stuck in the pull_request_queue, effectively on hold. That slow feedback loop isn’t just a minor inconvenience – it actively disrupts developer productivity. You can’t deploy, you can’t merge, and sometimes you can’t even comfortably start the next task because mentally you’re still attached to this one waiting for feedback. The meme exaggerates it as literally having nothing to do but stand around, highlighting the workflow disruption that such delays cause.

There’s also an implicit commentary on team culture and process. Modern version control platforms (GitHub, GitLab, etc.) make code reviews asynchronous: you push code, request review, and teammates review when they can. This is great for distributed teams, but the downside is the slow feedback loops that can arise. The meme is poking fun at how something meant to improve quality (code reviews) can ironically introduce friction when taken to extremes or when team bandwidth is low. It’s a kind of process debt: a well-intentioned practice that, if not managed, leads to waiting games. Every experienced developer has war stories of the “PR from hell” that stayed open for weeks waiting on approvals, during which time you get that nagging feeling of being unproductive.

The infinite loading spinner reference in the title encapsulates the feeling: just as a app can freeze on a loading screen, a developer can feel frozen in place waiting for a sign-off. The collage’s humor is that the man isn’t doing anything visibly “productive” – he’s literally standing with hands in pockets or gazing at trivial things. This is a tongue-in-cheek mirror of reality: maybe you start checking trivial details (like tidying your desk or scrolling aimlessly through emails) when you’re blocked on a review. It’s essentially a bottleneck in the DeveloperExperience (DX) – something that shouldn’t be a big deal but amounts to a significant idle_time_costs for the team. Everyone preaches continuous integration and rapid iteration, yet the reality often involves these waiting periods where you can do nothing but twiddle your thumbs or ping your teammate on Slack with a polite “gentle reminder.”

This meme resonates especially because it shines a light on a common anti-pattern in workplaces: asynchronous collaboration gone stagnant. It’s a reminder that code review processes need to be optimized too – whether through better team workflows (like explicit reviewer rotations, or even pair programming to avoid the queue) or tooling (like automatic reminders, or in some cases bypassing trivial reviews). The humor has an edge of truth: you can almost feel the frustration and boredom of the person waiting. In one frame he’s looking at ornate teacups – perhaps considering taking up tea brewing as a new hobby while his code sits unmerged. In another he’s face-to-face with himself in the mirror – the kind of existential reflection a dev might have: “Should I start another task or wait a bit more? If I start something new, the review will probably come back immediately; if I don’t, it’ll take all day.” It’s a comically accurate portrait of workflow disruption, where a usually fast-paced development cycle hits a human speed bump.

In summary, the meme cleverly encapsulates a DeveloperFrustration that engineers and even managers know too well. It highlights how a simple task like reviewing code can become a blocker, and it bonds over the shared experience of waiting. The absurdity of the man wandering from room to room is what makes it funny – it’s the physical world equivalent of constantly checking your inbox or refreshi ng the PR page to see if someone finally left a comment. It’s both cathartic and a bit of a dark joke about how even in high-tech workflows, sometimes you’re reduced to a person staring at the wall, waiting for a coworker’s thumbs-up.

Level 4: The Great Spinlock

In computing terms, this meme is highlighting a synchronization bottleneck in the development process. When a developer submits code for review, it’s like a thread hitting a lock and entering a spinlock – continuously checking for a condition (approval) that isn’t yet true. The developer (our "thread") has done their work and now must busy-wait for a teammate’s response. Nothing moves forward until that lock (the code review approval) is released. This is reminiscent of Amdahl’s Law, where the system’s speed is limited by its slowest sequential part. Here, the sequential part is the code review step: no matter how fast you wrote or tested your code, merging it is now a single-threaded operation gated by someone else’s action. In an ideal parallel world, you’d merge immediately and move on, but real-world collaboration imposes this serial checkpoint. Each panel of the meme – the man just standing around – symbolizes a loop iteration of this waiting state. It’s an infinite loading spinner because, until the review event occurs, the loop doesn’t exit. In pseudo-code, it’s almost like:

// Pseudo-code representing the wait for code review
while (!codeReviewDone) {
    // Developer is stuck here doing nothing productive 
    spin_wait();
}
mergeCode();

This busy-wait loop is the developer pacing in the kitchen, staring at paintings, inspecting teacups, and checking the mirror – a human thread context-switching to idle tasks. The humor here is that an ostensibly modern, asynchronous workflow ends up mimicking one of the least efficient concurrency patterns: a thread doing nothing but waiting. It’s a satire of process overhead, where the developer’s CPU cycles (brain and time) are burning on idle. In terms of queueing theory, the pull request queue is backed up: one slow reviewer acting as a single service node can cause tasks (PRs) to queue indefinitely. Little’s Law would tell us that longer queues mean longer wait times, and our lone developer is experiencing exactly that. So at the deepest level, this meme exposes how our fancy distributed version control and code collaboration still face a fundamental throughput problem – a human latency that no amount of automation can fully eliminate. The “infinite loading spinner” feeling is a byproduct of these inherent limits: like a program stuck on I/O wait, the dev is literally blocked by a real-world I/O – the Input of a review and the Output of an approval.

Description

A four-panel meme captioned, 'Me waiting for someone to review my code.' The panels depict film director Quentin Tarantino looking awkward, bored, and impatient in various parts of a house. He is seen standing in a kitchen, staring at a painting, looking down at a fancy tea set, and examining his reflection in a mirror. This meme format, sometimes known as 'Confused Travolta' but here with Tarantino, perfectly captures a sense of aimless and restless waiting. The technical context is the common developer experience of being blocked after submitting a pull request (PR). This waiting period for a code review is a frequent bottleneck in software development, disrupting a developer's flow and hindering team velocity. For senior engineers, it's a deeply relatable commentary on the importance of a swift and efficient code review culture

Comments

7
Anonymous ★ Top Pick I've had Kubernetes deployments finish faster than getting a 'looks good to me' on a three-line CSS change
  1. Anonymous ★ Top Pick

    I've had Kubernetes deployments finish faster than getting a 'looks good to me' on a three-line CSS change

  2. Anonymous

    I’ve accepted that our review stage runs under the BASE consistency model: basically available, sometimes engaged - eventually someone will click “Approve.”

  3. Anonymous

    The same energy as refreshing the CI pipeline that's been "waiting for runner" for 20 minutes, except at least the runner has an excuse - it's probably mining crypto

  4. Anonymous

    The real technical debt isn't in the code - it's the compound interest accruing on your mental context while that PR sits in review limbo for three sprints. By the time you get feedback, you've already refactored that module twice in your head and forgotten why you made those architectural decisions in the first place

  5. Anonymous

    PR review wait times prove CAP theorem's P: even in distributed teams, partition tolerance trumps timely approval

  6. Anonymous

    CI: 8 minutes. Human reviewers: eventual consistency with unbounded tail latency - my PR is basically S3 Glacier

  7. Anonymous

    Our DORA dashboard says lead time is 3 days - 2.9 of them waiting for CODEOWNERS to release the distributed lock called LGTM

Use J and K for navigation