Programming: Expectation vs. Contemplation

Level 1: Waiting in Line

Imagine you see a cool superhero movie where the hero is using a computer with all these crazy graphics, typing a million lines a minute, and doing exciting stuff non-stop. It makes being on the computer look like an action video game, right? Now think about a time you went to an amusement park, like Disneyland. You probably dreamed about all the fun rides and thrills you’d have. But what really happened? You spent a lot of time waiting in line for each ride. Sure, the rides were awesome and exciting, but between those few minutes of excitement, you might have stood around for an hour doing nothing, just inching forward in the queue, looking around bored.

Being a programmer is a lot like that. People think it’s all fast and thrilling like the movie scenes – typing furiously on a glowing screen and bam! cool stuff happens. But really, a lot of the time it’s like standing in that long line waiting your turn. We do a bit of work (the fun part, like the ride) and then we have to wait while the computer does its work (the boring part, like waiting for the next ride). The meme is showing that difference. The top picture is the imagination – programming as one big roller coaster of constant action. The bottom pictures show the reality – a programmer sitting around looking bored, waiting for things to finish, just like you waiting and staring into space in a slow line. It’s funny in the same way it’s funny when someone says, “Being an adult is 10% fun and 90% doing laundry.” It uses exaggeration to make a point.

So the joke is basically: Programming isn’t always as exciting as it looks in the movies. A lot of times, it’s as boring as waiting for your turn on the swing. And just like you might hum a song or play "I Spy" to pass the time in a line, programmers find little ways to pass the time (maybe getting a coffee or chatting) while waiting for their code to finish working. We can laugh at it, because it’s a little bit silly that something that seems so high-tech and magical actually involves quite a bit of good old-fashioned patience.

Level 2: Progress Bar Purgatory

Let’s break down what’s going on here in simpler terms. This meme highlights the gap between how non-developers imagine coding and what developers actually do most of the day. The top image – the one with glowing code and sci-fi graphics – represents the popular image of a programmer at work. Think of any TV show or movie where they show hacking: the screen is full of rapidly changing numbers, 3D bar charts, rotating encryption ciphers, or just crazy binary code rain (like that famous green cascading code from The Matrix). In real life, programming usually doesn’t look like that at all. We typically work in a normal-looking environment – maybe an IDE (Integrated Development Environment) or a plain text editor or terminal – and it’s pretty static visually. No neon 3D graphics, just normal text on a screen. The meme’s caption calls out “How people think programming looks” because many people (who don’t code) assume it’s super visually exciting or mysterious. That’s the illusion part of this illusion-vs-reality comparison. It’s a bit like thinking every chef is tossing knives and flames like a teppanyaki show, whereas most of the time they’re actually just chopping veggies methodically.

Now, the bottom part of the meme is showing what programming really looks like most of the time: a person waiting around, bored. Those three images of a lonely man sitting and staring into space are from the “sad Pablo Escobar” template. This became a popular meme format to represent someone waiting or feeling bored and isolated. In the context of coding, it’s used here to say, “Yup, this is me 90% of the time as a developer – just waiting.” The caption confirms it: “How it really looks 90% of the time.” So, what exactly are developers waiting for?

A huge chunk of a programmer’s day can be spent waiting for various build processes and tools to finish their work. For example, when you write code, you often need to compile it. Compilation is when your source code (the stuff you wrote in a language like C++ or Java) gets processed and transformed into an executable program or machine code that the computer can run. This can take some time, especially in big projects. You might run a command like make or npm run build or mvn compile, and then you watch as the computer churns through your code. You’ll see a progress bar or a lot of text logs flying by, indicating which files are being compiled or what tasks are being done. During this, the CPU is busy but the developer isn’t actively typing – you’re essentially waiting_for_compilation to complete so you can test or run your program. It’s a bit like hitting “Bake” on an oven: you did all the mixing, now you just have to wait for the cake to bake.

Beyond just compiling code, modern software development involves automated build pipelines and CI/CD systems. CI stands for Continuous Integration, and CD stands for Continuous Delivery/Deployment. These are fancy terms for automated processes that run every time you make changes to your code (especially when working with a team). For instance, when you push your code changes to GitHub or your company’s repository, a CI server (like Jenkins, CircleCI, or Travis CI) will automatically pick up the changes and run a series of steps: it will compile the code, run all the test cases, maybe build installer packages or Docker images, and sometimes even deploy the new version to a testing environment. This whole chain of actions is what we call a build pipeline or CI pipeline. It’s super useful because it ensures that code is tested and built consistently every time. However, it also means you, the developer, might be stuck twiddling your thumbs while all these steps execute. You can’t rush it – if the pipeline takes 10 minutes to run all the tests, you have to wait those 10 minutes to see if your changes passed or if something failed. This waiting can feel excruciating, especially if you’re eager to know whether that bug you fixed is truly gone. It’s a major cause of DeveloperFrustration for many of us. We want to be productive, but we’re blocked until the tools finish their work.

Let’s imagine a typical scenario step by step to see why Pablo is so sad in the meme:

1. Write code: You add a new feature or fix a bug in the code. (This might take a few minutes or a few hours of active work.)
2. Start the build: You trigger a build/test run. Maybe you type npm run build or you push your code and a CI/CD pipeline kicks off on a server.
3. Compilation and processing: The build system starts doing its thing – compiling code, bundling files, running automated tests. During this time, you see messages like “Compiling module 5 of 18…” or a progress bar slowly moving. Your machine (or the CI server) is working hard, but you can’t really speed it up by typing more. You’re essentially in a holding pattern.
4. Wait for results: This is where the waiting happens. Could be 30 seconds for a small project, or 30 minutes for a huge one. You might literally watch a progress bar (hence the tag idle_progress_bar_stare – the act of staring at a loading bar doing nothing). Many developers take this time to stretch, check their phone, or daydream just like Pablo in that meme. You feel a bit unproductive, but there’s no point in starting a complex new task because any second now, the build might finish… any second… yawn.
5. Build complete: Finally! The build succeeds (or fails). If it fails, you have to go back to step 1, fix something, and go through the cycle again. If it succeeds, great – you maybe run the app to try it out or, if it’s CI, you merge the code knowing it’s all good. Then it’s on to the next bit of work, which soon enough will require… another build and more waiting.

This cycle can repeat many times a day, which is why the meme says “90% of the time.” It’s exaggerated for effect (we do actually get some real work done, promise!), but sometimes it feels like 90% waiting, 10% coding. Especially on a day when the tools are being sluggish or something in the pipeline is acting up. If you’ve ever sat watching a loading spinner or a test counter (like “Tests running: 150/800 completed...”), you know the feeling. That’s the Progress Bar Purgatory – you’re stuck in a state of almost done, but not quite, and there’s nothing to do but wait and maybe daydream.

The meme also touches on DeveloperExperience_DX and DeveloperProductivity indirectly. Developer Experience (DX) is a concept that means how pleasant or efficient it is to do your work as a developer. Fast build times, good tools, and efficient processes improve DX, whereas slow, painful waits hurt DX. When builds and CI pipelines take too long, it breaks your flow. Imagine if you were painting and had to wait 10 minutes every time you mix a new color – you’d lose inspiration pretty quick! Similarly, in coding, when you have to constantly wait, it can be quite frustrating. It’s a hit to DeveloperProductivity because time spent waiting is time not spent building features or fixing bugs. Teams acknowledge this as a big issue: that’s why there’s always an effort to speed up the build process, whether it’s by using better hardware (faster computers or servers), caching build results so you don’t recompile everything every time, or breaking a big project into smaller modules that can compile faster independently. But no matter what, on real teams there will still be some waiting around. It’s almost a running joke in every programmer’s career that at some point you’ll utter the phrase “Well, time to get coffee, the build is running.”

Another thing the meme hints at is how outsiders’ perceptions of coding can be so off-base. Non-developers might think we’re constantly doing intense, glamorous work because that’s how media portrays hacking/coding. In reality, a lot of programming is reading (reading documentation, reading error messages) and waiting (waiting for the computer to do its part). It’s not visually exciting from the outside. If someone were to “watch” you work, a lot of the time it might look like you’re just staring blankly at a screen (you might be mentally debugging or just waiting for a process). The Sad Pablo images capture that outsider view perfectly: to others, the programmer looks like a bored person doing nothing, not the movie-style hacker wizard. That disconnect is exactly why this meme is both funny and a little bit comforting to developers. It says, “Hey, you know that super dull part of your day where you’re just waiting and feeling unproductive? We all have that. You’re not alone.” It’s classic DeveloperHumor where we laugh at our own reality.

In summary, the top of the meme = glamorous myth (coding as seen in movies, all action and cool visuals), and the bottom of the meme = everyday truth (coding in real life, a lot of waiting and boredom). If you’re new to programming (maybe a junior dev or a student), don’t be surprised when you encounter this. The first time you have a project where hitting “Run” or “Build” means you have a 5-minute lull, you’ll remember this meme. It’s a gentle warning and a joke all in one. And for those of us who have been around a while, it’s a wink and nod: Yep, we’re basically Pablo sitting on that swing while our test suite runs. Keep some good music or a second task handy – that’s the life of a coder too!

Level 3: The Matrix vs. Maven

At first glance, this meme pits Hollywood’s flashy coding illusions against the gritty reality of everyday development. In the top panel, we see a neon-blue cascade of binary digits, 3D hexagonal HUD overlays, and code scrolling dramatically – basically the quintessential Hollywood hacking montage. It's the kind of cinematic coding cliché where a protagonist furiously types while futuristic code dances on multiple screens. To seasoned engineers, this screams “unrealistic_cinematic_coding”: real code never looks that glamorous on our monitors. The caption cements the joke – “How people think programming looks” – highlighting the myth that programming is an action-packed visual spectacle.

Now contrast that with the three frames below: the Sad Pablo Escobar template from Narcos, depicting the character sitting alone on a swing, slumped at a table, and standing aimlessly by an empty pool. The overlaid text: “How it really looks 90% of the time.” This stark juxtaposition nails a truth every developer knows all too well. Rather than hyper-kinetic code rain from The Matrix, developer reality often feels like an exercise in patience – waiting for the code to compile, for tests to pass, or for a deployment to finish. The meme cleverly uses Pablo’s lonely, bored posture as a metaphor for the programmer’s life during those long stretches of inactivity. It’s an illusion_vs_reality_meme that draws its humor from shared experience: outsiders picture us as keyboard cowboys in a digital rodeo, while we actually spend chunks of our day staring at progress bars and loading spinners.

Why is this so relatable? Because 90% might not even be an exaggeration on some days. Modern development involves a lot of “hurry up and wait.” You write a few lines of code or fix a bug, kick off a build, and then … you wait. And wait. And maybe grab a coffee. In large projects, a full build process can take several minutes or more, especially in compiled languages (hello C++ or heavy Java apps with mvn package). Continuous Integration (CI) servers might have a queue of jobs, so your build is 10th in line – cue the classic ci_queue_boredom. Even running a test suite can feel glacial if there are hundreds of tests or if end-to-end integration tests hit remote services. The result? You find yourself reenacting the Sad Pablo pose, gazing at the screen or the ceiling, stuck in what one might call Progress Bar Purgatory. The meme resonates because it spotlights this compile-and-wait loop that’s a staple of the developer experience (DX). It’s a form of developer frustration we don’t often advertise, but we all collectively sigh about it. In fact, entire tools and practices in BuildSystems_CICD exist to minimize this downtime – from incremental compilation to hot-reload frameworks – yet in practice, the wait persists like an inevitable Monday morning.

From a senior engineer’s perspective, the humor cuts deep: we’ve all lost momentum because of a slow build. That moment when you’re “in the zone” solving a problem, then have to rebuild the project and suddenly you’re in limbo. It’s practically a rite of passage in software development. We joke about it in DeveloperHumor threads and DeveloperMemes, but it has real impact on DeveloperProductivity. Think of a complex front-end project: you make one small CSS change and then gulp/webpack churns for minutes. Or a huge codebase where a full compile gives you enough time to scroll Twitter, read email, and reconsider your life choices. :smirk: The shared trauma is exactly why the meme elicits that knowing, painful chuckle. It’s pointing at the elephant in the room: the BuildPipeline meant to automate our work often leaves us twiddling our thumbs.

The contrast with Hollywood-style hacking makes the meme even funnier for industry veterans. We’ve seen movies where a “genius coder” smashes on the keyboard and accidentally opens a 3D skull hacker interface or decrypts files in seconds with a dramatic progress bar racing to 100%. Meanwhile, back in reality, our actual progress bars crawl like molasses in winter. If real programming were shown accurately on film, the audience would be treated to long shots of a developer sipping coffee, checking their phone, and sighing at a screen that says Compiling... 42%. Not exactly blockbuster material! So directors opt for glowing hex grids and rapid-fire gibberish code to keep things exciting. We developers laugh because we wish our day-to-day had even a fraction of that excitement. Instead, we get rituals like:

$ npm run build   # Start the build process (time to pray to the CI gods)
... 
Updating dependencies...
Bundling modules...
Optimizing...  (takes forever)
... 
Build finished in 4m 37s. 

// Meanwhile, developer has finished a coffee and is staring into the abyss.

Over years of this, devs develop coping strategies. You’ll see a bunch of us around the foosball table or in the break room with the excuse “the code is compiling.” There’s even an old joke in a comic (looking at you, XKCD) where two programmers are found lounging: “Are you guys slacking off?” “Nope, our code is compiling.” It’s funny because it’s true – we often can’t do anything but wait during those intervals. And woe betide the engineer whose build fails at the end of a 20-minute cycle – that feeling is pure agony, knowing you have to fix one line and then wait another 20 minutes. :grimacing: Seasoned devs have felt that 3 AM adrenaline drop, when you deploy a hotfix during an outage and spend long minutes watching a deploy log scroll slowly, heart pounding, while some manager imagines you’re furiously hacking the Gibson. Nope – you’re just alone with your thoughts, like poor Pablo, whispering “please, please let it compile this time.”

In short, this meme lands so well because it speaks the developer reality that unites us: real programming isn’t an action movie scene; it’s a slog of brilliant problem-solving peppered with mind-numbing waiting. The top-half is the illusion outsiders (and junior devs fresh from watching hackers in movies) might believe. The bottom-half is our reality – equal parts frustrating and comical in hindsight. Every engineer who’s ever stared at an idle_progress_bar_stare or watched a test runner tick through 1,000 cases with dull inevitability can relate. It’s DeveloperHumor at its finest, because it validates our daily grind with a wink: you’re not the only one bored senseless by your fancy automated pipeline. We’ve all been that meme, sitting like Pablo, waiting for the magic to happen.