By 2021, the rest of the world had moved through two entire generations of PHP without this server noticing. It was still running 5.4 on RHEL 6, like handing someone a rotary phone and asking them to keep up with a group chat.
That’s the actual machine a slow dashboard was fighting on, and it’s worth being precise about the gap. PHP jumped straight from version 5 to version 7 in 2015, skipping 6 entirely, so this server hadn’t just missed one release cycle, it had missed the entire PHP 7 line and the early PHP 8 releases both, running code on an interpreter that predated performance improvements the rest of the ecosystem had been living with for the better part of six years. RHEL 6 told the same story. Officially past its own supported life, on hardware that had almost certainly outlived its intended service window years earlier, quietly holding up more than 150 small internal applications that all depended on it working.
My own mistake, first
Before any of that becomes the villain of the story, it’s only fair to admit I wasn’t exempt from writing slow code myself. This was an internal dashboard, somewhere around 100 to 200 rows of data, nothing that should have been remotely difficult to render. I built it the way most of the industry had been teaching for the better part of a decade: everything should be an object. Pull the rows back from the database, wrap each one, pass a clean array of well-encapsulated objects down to the view layer. It’s the kind of decision that looks correct in a code review. It ran slow as molasses.
I caught it quickly, because the shape of the problem was obvious once I actually went looking for it: the object wrapping itself, not the query, not the data, was the expensive part. I swapped the array of objects for a plain array of associative arrays, same underlying data, no wrapper class sitting on top of each row, and the page came back to life instantly. Nothing else changed. The fix was removing a layer of structure I’d added purely out of habit.
A junior developer’s mistake, years later, from the opposite direction
Years after that, on a completely different project, a junior developer on the team ran into the inverse version of the same lesson. He’d pulled a raw SQL result set directly into an array on the backend, and every time the frontend needed a specific value out of it, the code looped through the entire array from the beginning, comparing each entry, until it found a match. No early exit once found. Just a full scan, every single lookup, against roughly 130 rows.
On its own, that’s not expensive. A plain linear scan over 130 items is nothing on modern hardware, done before you’d notice it happened. But this particular application wasn’t running on modern hardware. It was running on that same PHP 5.4, RHEL 6 machine, competing for scraps of CPU against 150 other applications all sharing infrastructure that should have been retired the better part of a decade earlier. Layer a full linear scan on top of that, repeated for every single value the page needed, and it blew straight through the platform’s 30-second timeout, every single time it ran. He’d been staring at it, unable to figure out why, because from where he was looking, the code was doing exactly what he’d told it to do. On different hardware, it probably would have been.
I looked at it for about five minutes. Reshaped that same array into an associative array, keyed by the value being searched for, so a lookup became a direct hit instead of a search. The entire loop he’d been trying to optimize simply had nothing left to do. It wasn’t a matter of writing the loop more efficiently. The loop wasn’t supposed to exist at all.
Two mistakes, one lesson, and an ancient server that made it impossible to ignore
Two different mistakes, years apart, opposite instincts, and one of them was mine. Mine came from over-structuring data that didn’t need structure. His came from under-structuring data that needed exactly one thing: a way to look something up without scanning for it. Different shapes, same underlying failure: the format you choose for your data determines what it costs to use, and that cost doesn’t announce itself in how the code reads. It shows up when someone actually runs it, and it shows up a lot faster and a lot harder when the hardware underneath has been quietly falling behind for years without anyone budgeting the time to catch it up.
What experience actually buys you
Here’s the part I keep coming back to. I didn’t get to skip making a version of this mistake myself. Nobody does. What changed with time and experience wasn’t some immunity to writing the wrong shape of code. It was speed, recognizing the actual shape of a slow problem quickly enough to fix it myself, rather than staring at a 30-second timeout with no idea where to even start looking.
That same reflex, reaching for the conventionally “correct”-looking answer instead of the cheap one that actually fits the problem, is still the default move an AI coding assistant makes for you today, unless you’re paying close enough attention to catch it. The lesson didn’t retire when the frameworks changed. It just changed which tool hands you the first draft, and it’s still just as easy to hand that draft off to hardware that was never going to forgive the mistake the way modern infrastructure quietly does.