Dancing With Global State

Level 1: The Shared Remote

Global variables are like one TV remote that everyone in the house can grab and change without saying anything. If the channel suddenly changes, you do not know who did it or why. The meme is funny because the programmer knows dancing with that shared remote is a bad idea, but it still looks tempting when it saves time.

Level 2: Anywhere Means Everywhere

A variable is a named place where a program stores a value. A global variable is available across a large part of the program, sometimes everywhere. That can be useful for constants or configuration, but it becomes dangerous when many parts of the program can change it.

For example:

let currentUser = null;

function login(user) {
  currentUser = user;
}

function canEditDocument() {
  return currentUser && currentUser.role === "admin";
}

This looks simple, but canEditDocument() depends on something that is not passed into it. If another part of the program changes currentUser, the behavior changes too. That is a SideEffectsInProgramming problem: code has effects outside its visible inputs and outputs.

Better designs often pass values explicitly, keep state inside smaller modules, use dependency injection, or isolate shared state behind clear interfaces. The goal is not “never share anything.” The goal is to make sharing obvious enough that future developers can reason about it without dancing blindfolded.

Level 3: Shared State Waltz

The image labels the blindfolded dancer:

me

and the red dancing partner:

global variables

That pairing is the entire warning label. The dancer is not being dragged; she is participating. That is what makes the meme painfully accurate. Developers usually do not end up with global state because they love chaos in the abstract. They use it because, in the moment, it is convenient, visible from everywhere, and faster than threading dependencies through five layers of code that were apparently designed during a meeting with no exit criteria.

The blindfold matters. Global variables hide the path between cause and effect. A function can read or mutate state without declaring it in its parameters or return value. That makes the code feel easy at the call site and expensive everywhere else. When something changes unexpectedly, the debugging question stops being “what did this function do?” and becomes “which part of the entire process touched this shared value before I got here?”

This is why global mutable state is such a durable AntiPattern. It creates hidden coupling. Tests become order-dependent because one case can contaminate another. Refactors become risky because callers rely on invisible ambient context. Concurrency makes it worse because two paths can observe or modify state at awkward times. Even without threads, UI apps, request handlers, background jobs, and plugin systems can all turn globals into a communal junk drawer with production permissions.

The post message says, Looks like I should post a little bit less about global variables..., which suggests the joke is part confession, part recurring trauma. Every experienced developer has seen a “temporary” global become the unofficial system bus. At first it saves time. Later it requires rituals, reset hooks, defensive cloning, and one senior engineer who knows which assignment must never move. That is not architecture. That is oral tradition with semicolons.