The Zen of Code Reviews: i == i

Level 1: A Rule That Does Nothing

Imagine you have to go through a list of chores, and someone tells you: “For each task, if the task is itself, then skip it.” Huh? 🤨 That rule is nonsense because a task is always itself! It’s like saying, “if an apple is an apple, don’t pick it.” That condition is always true, so you’d end up skipping every single task and never actually doing any work. In this meme’s story, a programmer wrote a rule exactly like that in their code – an always-yes rule that ends up doing nothing. When the programmer’s teammates saw this, they were completely baffled. One person basically pointed at the silly rule, and another got so frustrated they jokingly pretended to flip a table over (using a funny text emoji). It’s amusing because the rule is obviously pointless and everybody can see it. The team is half-laughing and half-groaning, like when a friend makes a really bad joke or a silly mistake. The humor comes from how ridiculous the situation is: a do-nothing rule that slips into the work, and the dramatic “UGH!” reaction it gets from everyone who spots it.

Level 2: Reviewer Tableflip

What we have here is a screenshot from a GitHub pull request showing a piece of code and some comments from colleagues doing a code review. The code in question has a simple for-loop:

for (let j = 0; j < pointsToFilter.length; j++) {
    if (i == i) {
        continue;
    }
    // ... some code that would run if the if condition were false
}

Let’s break that down in plain terms. There are two loop variables, probably i from an outer loop and j from this inner loop (we see pointsToFilter.length, suggesting maybe they’re looping over a list of points). Inside the loop, there’s an if (i == i) check. Normally, an if statement is used to make a decision: it runs the inside block only if the condition is true. Here the inside block is continue;, which means "skip the rest of this loop iteration and move on to the next one."

The issue is that i == i will always be true. It’s like asking, “is this thing equal to itself?” Of course it is – any value equals itself by definition. In programming, unless something crazy is going on, x == x is true for any normal number, string, etc. (One rare exception in JavaScript is NaN (Not-a-Number), which is a special value that isn’t equal to itself. But here i is an index in a loop, almost certainly a regular number, not NaN.) So this condition doesn’t actually check anything meaningful – it’s true every single time.

Because that if condition is always true, the code will go into the continue every time. The continue causes the loop to immediately jump to the next iteration of j, skipping any code that would have come after the if. In the snippet, they don’t even show any code after it (probably because nothing else happens in that loop). Effectively, the programmer put in a rule that says “if i equals i (which it does), skip doing the rest” for each loop run. The inner loop, therefore, does nothing at all! It just iterates through j values and continuously says “skip, skip, skip...”. This is almost certainly a bug. Most likely, the intention was to use a different condition – for example, a common pattern would be if (i == j) continue; to skip cases where the two indices are the same (perhaps to avoid comparing an item with itself). But by writing if (i == i) instead, the programmer essentially wrote a nonsense check. It’s a redundant condition that doesn’t serve any purpose except to make the code incorrect.

Now, in a pull request code review, other developers will leave comments on lines of code that seem off. In the image, Reviewer 1 comments with just i == i. on that line. They’re basically pointing at the exact code and saying, “Ummm… this looks wrong.” It’s a very succinct way to flag the issue. They didn’t even ask a full question – just highlighting it is enough to say, “This line makes no sense, care to explain?” It’s a bit of a dry, deadpan call-out.

Reviewer 2 comes in with a reply using a kaomoji: (╯°□°）╯︵ ┻━┻. A kaomoji is a Japanese-style emoticon built from text characters (you can see a little face in there and a table being flipped). This particular one is famous for meaning “I’m flipping a table in frustration!” It’s like an online-cartoon way of showing that you’re so frustrated or shocked by something that you metaphorically throw a table over. People often use it jokingly when something is ridiculously annoying or dumb.

So why is the second reviewer “flipping a table”? Because finding a line like if (i == i) in code can be pretty frustrating (and also darkly funny). It’s a really obvious mistake – one that shouldn’t be in the code at all. The reaction is dramatic on purpose to add some humor: the reviewer is basically saying, “This code is so absurd it makes me want to flip a table!” Of course, they’re not actually angry to the point of violence; this is just how developers sometimes express a facepalm moment in an entertaining way. It shows that the team is comfortable joking around. They’re frustrated, yes, but also likely chuckling as they write that emoticon. It’s a form of coding humor during the review.

This scenario highlights a common pain point in code reviews: catching simple errors that can break logic. On one hand, everyone’s relieved that the review process caught it before the code went into the product. On the other hand, it’s a bit exasperating to review code that has such an obvious issue. It can make you think, “Did the author even run this code once?” In a collegial team, the response might be light-hearted ribbing, like we see here. The first reviewer’s terse “i == i” comment and the second’s table-flip emoji are both playful ways of saying “This line is ridiculous; please fix it.” It’s both a critique and a shared laugh.

Also, notice the use of == in the code (the double equals). In JavaScript, == is the loose equality operator, which means it tries to be flexible with types. For example, if i were the number 5 and you compared it to the string "5" with i == "5", JavaScript would say true, because == converts the string "5" into the number 5 behind the scenes. There’s another operator === (triple equals) that checks equality without converting types, which is generally safer – e.g. 5 === "5" would be false, since one is a number and one is a string. Many style guides insist on using === to avoid confusion. Here, the developer used ==. In this particular case, it doesn’t actually cause a bug – i == i would be true with either == or === since the two sides are literally the same thing and already the same type. But seeing == might irk some JavaScript reviewers because it’s considered less clean. It’s like the cherry on top of this mistake: not only is the if check pointless, they also didn’t use the stricter equality operator. It’s not the main issue at all, but it contributes to the impression of sloppy code.

In summary, this meme captures the moment a code reviewer discovers a silly mistake: an always-true condition in the code that makes the code do nothing useful. The reviewers react with a mix of snark and humor — one highlighting the nonsense line, another figuratively flipping a table. It’s funny to developers because we’ve all seen or made mistakes like this, and sometimes the best (or only) response is to laugh, tease a bit, and then fix the code. The whole thing underscores why code reviews are important (to catch bugs like this), and it gives a nod to the camaraderie and joking that often happens on software teams when dealing with goof-ups.

Level 3: Trivially True, Truly Pointless

In this code review screenshot, the diff highlights a trivial equality check: if (i == i). Any seasoned dev immediately recognizes this as a tautology – a condition that’s always true. It's like writing if (true) in the code. In fact, the snippet effectively becomes:

for (let j = 0; j < pointsToFilter.length; j++) {
    if (true) {               // i == i is always true
        continue;
    }
    // ... (this code never runs)
}

The continue inside means "skip to the next loop iteration." Since the if condition is constantly true, the loop always hits continue on the first line and skips everything after. In other words, the inner loop does nothing at all – a complete no-op. This is a classic code smell and likely a bug: perhaps the developer intended to write if (i == j) (to skip an element comparing with itself in a double loop) but mistakenly wrote i == i. As it stands, it's a brilliant optimization useless piece of logic that nullifies the entire loop.

During a code review, coming across a line like if (i == i) is a facepalm moment. It's the kind of bad practice that reviewers are there to catch. The screenshot shows a GitHub pull request diff with two reviewers commenting. The first reviewer simply comments "i == i.", basically quoting the line with a hint of peer review snark: an understated way of saying "Uhh, what is this?". The second reviewer responds with the infamous kaomoji (╯°□°）╯︵ ┻━┻. This text emoji depicts a person flipping a table in frustration. In dev culture, a table-flip emoji is a dramatic but humorous way to express “I’m so done with this nonsense.” The use of such an emoticon in the PR hints that the team has a sense of humor and that the code is so absurd it provokes cartoonish outrage.

Why all the drama over one line? Because if (i == i) is glaringly pointless and potentially dangerous. It shows poor code quality – either the author was careless or doesn’t understand what they wrote. It’s also a subtle JavaScript inside-joke: the code uses == (loose equality) instead of === (strict equality). In JavaScript, using == can lead to weird type-coercion issues (like 0 == "0" is true), and many devs insist on === for clarity. Here, however, whether it was == or === doesn’t really matter – comparing a variable to itself is always true either way (unless that variable is the notorious NaN, which isn’t equal to itself – but expecting that here would be giving too much credit 😏). The fact that it’s a double-equals just adds a bit of extra “ugh” for style: it’s like the coder managed to ignore two best practices in one go.

From a senior engineer’s perspective, this scenario is painfully relatable. We’ve all reviewed code where something is so obviously wrong it makes you doubt your own eyes for a moment. Is there some clever trick I’m missing? Nope, sometimes it really is just an oversight. Here the redundant if statement is a logical no-op, likely introduced by a copy-paste or a sleepy coder at 3 AM. It’s both funny and frightening to see it in a PR because it makes you wonder what other bugs might be lurking if this got through. The humor comes from the shared experience of catching such an elementary mistake and the exaggerated reaction to it. The reviewers’ comments exemplify how dev teams often cope with absurdities: a mix of sarcasm, meme-worthy reactions, and genuine bafflement. It’s a small reminder that in programming, bugs come in all shapes – sometimes even as an if condition that always says “yes,” leaving everyone scratching their heads (and flipping tables).