Behind the Code

We’ve all experienced that moment in our job: 1 p.m., deadline in 4 hours, and you stare at your screen thinking: “OK, this solution isn’t elegant, but it works… Am I a fraud?”

As developers, we put huge pressure on ourselves. We devour articles about design patterns, we religiously follow conferences where every line of code sounds like poetry, we browse open-source code that breathes elegance. And when our own code looks less like architectural genius and more like a shack held together with duct tape, we feel guilty.

We tell ourselves we’re not good enough. That we should do better. That “real” developers don’t need sketchy workarounds.

But here’s the truth no one dares to tell you: Apple, Nintendo, Bethesda — all the giants you admire — use hacks. Big ones. Very messy ones even. And they still ship products that millions of people use every day without blinking.

Let’s start with an example that made me smile: the clock in the iPhone Alarm app.

You know, that nice time selector that feels like it scrolls endlessly through hours and minutes? That smooth, satisfying scroll that seems to loop forever?

Well, it’s not a loop. It’s just… a very, very long pre-generated list of hours.

Yes, yes 🫢. Apple, with its gigantic budget and armies of brilliant engineers, just said: “Let’s generate a huge list.”

No sophisticated infinite-loop algorithm. No advanced UI component with dynamic repositioning. Just a list. Period.

Why this choice? Most likely for performance reasons. Dynamically repositioning elements at the top of the list while keeping ultra-smooth scrolling at 60 fps was probably too resource-hungry. So instead of fighting the constraints of iOS’s rendering engine, they took the path of brutal simplicity.

Let’s stay in the absurd: the subway sequence in Fallout 3.

In the game, you get to travel quietly inside a post-apocalyptic subway car, watching the tunnel go by through the windows. An immersion into the underground ruins of Washington D.C.

Well, you’re not in a train. You just have a giant subway car attached to your head, and you’re running very fast on the tracks.

Yes, yes 🫢. Bethesda, the studio behind one of the biggest RPG franchises ever, literally equipped the player with a massive 3D train model, made them run at full speed along the rails, and placed the camera in first-person view.

Why this choice? The Gamebryo engine (the one used for Fallout 3) simply didn’t support moving vehicles. No physics system for transportation, no proper camera handling, nothing. Bethesda could have spent months building a full vehicle system… for one 2-minute sequence.

So they took the path of brilliant hacking: reuse what already existed (the player, equipment, run animations, and camera) and completely repurpose them.

Now let’s talk about an illusion you’ve probably experienced without ever noticing it: horse sprinting in video games.

In most games, you have two movement speeds: walk or run. On horseback, same thing: trot or gallop. You press the sprint button, your horse dashes forward, mane in the wind, and you feel that boost of adrenaline. You’re clearly going faster, right?

Well, in Dragon Age: Inquisition… no. You’re not going any faster. Not at all. Your horse trots at exactly the same speed as before.

Yes, yes 🫢. BioWare, the studio behind Mass Effect, lied to you straight in the eye. When you “sprint” on horseback, the actual speed doesn’t change by a single pixel. They simply added speed effects and shifted the camera to make you feel like you’re going faster.

Why this choice? The Frostbite engine (yes, the Battlefield one) couldn’t load Dragon Age’s environments fast enough to support a real speed increase. If your horse actually went faster, you would hit unloaded textures, constant pop-in, or even crashes.

So instead of rebuilding the whole asset-streaming system, BioWare chose the quickest solution: make you believe you’re going faster to give the impression of speed. And guess what? It works perfectly.

Let’s continue with a Nintendo 64 classic: the sky in The Legend of Zelda: Ocarina of Time.

You remember those moments when you lifted your eyes toward Hyrule’s sky? That seemingly infinite firmament, those peacefully drifting clouds creating an epic, contemplative atmosphere that marked an entire generation of players?

Well, it’s not a real sky. It’s just… a giant cardboard box turned upside down around your head.

Yes, yes 🫢. Nintendo, the absolute masters of game design and optimization, didn’t create a complex atmospheric system. They simply took a giant cube, flipped it, applied sky textures on it, and placed you inside.

Why this choice? The Nintendo 64, revolutionary as it was, simply didn’t have the power to calculate a realistic sky. No fancy shaders for light dispersion, no Rayleigh scattering, no real-time volumetric clouds.

So Nintendo did what Nintendo does best: take a technical limitation and turn it into artistic strength. A simple textured box, always centered on the player to give the illusion of an infinite horizon, with just enough detail for your brain to fill in the gaps.

Let’s stay in the Zelda universe but move forward a few years with Breath of the Wild and its most iconic event: the Blood Moon.

You know the scene: the sky turns blood-red, eerie music rises, Zelda speaks to you in voice-over to warn you that Ganon’s power is reborn, and every enemy you painfully defeated returns. A powerful narrative moment reinforcing the omnipresence of evil across Hyrule, right? And one that appears regularly to regenerate the game loop.

Well, it’s mostly… a garbage collector disguised as an epic cutscene.

Yes, yes 🫢. Nintendo once again turned a critical technical constraint into a narrative event. When the Switch starts choking under the weight of your actions (items picked up, enemies killed, trees cut, world state changed), the game triggers a Blood Moon to clear the RAM.

Why this choice? Breath of the Wild is a massive open world where everything is persistent and interactive. Every apple picked, every bokoblin killed, every chest opened stays in memory. On a small portable console with limited resources, that quickly becomes unmanageable.

Instead of forcing loading screens, Nintendo had a stroke of genius: turning this technical necessity into a gameplay moment. The Blood Moon isn’t a bug; it’s a feature. It has narrative meaning, creates tension, keeps you alert, and above all… no one suspects it’s saving your game from crashing.

To finish this gallery of hacks, I saved the best for last. The alpha and omega of hacks turned legend: Space Invaders (1979).

You definitely know this iconic game, even if you’ve never played it. And you especially know this moment: at first, the aliens descend slowly, almost lazily. But as the game goes on, they speed up. Faster and faster. Until that unbearable tension where you can barely breathe between shots. It’s the essence of the gameplay — perfect dramatic buildup, pure game design.

Except this progressive acceleration, this perfectly calibrated crescendo… nobody programmed it.

Yes, yes 🫢. There is not a single line of code in Space Invaders that speeds up the game. Zero. Nada. Nothing.

The truth? At the start of the game, the 1979 processor is overwhelmed. Calculating movement for 55 aliens, handling all possible collisions, playing the iconic music (beep… beep… beep…), drawing everything on screen — it’s struggling. The game is slow because the CPU is crawling.

But when you kill aliens, magic: the processor has less work to do. Fewer entities to move, fewer collisions to check, fewer sprites to display. It can breathe again. And since the game loop runs “as fast as possible,” it… runs faster. Naturally. Mechanically.

Next time you rush your code and look at your slightly dirty hack wondering if you’re an impostor, remember:

The best developers aren’t the ones who never hack. They’re the ones who know when to do it, how to document it properly, and when to come back and clean it.

Perfect code doesn’t exist. Code that changes people’s lives does.

❤️ Heart to your keyboards.