The terminal blinks at me, a rhythmic pulse of green light against a sea of dark 0s and 1s, and I’m clicking the refresh button for the 37th time this morning. It’s a mindless gesture, a digital nervous tic. My latest pull request is sitting there, 107 lines of elegant logic designed to fix a race condition that has been haunting our production logs for 17 weeks. It is ready. It is tested. It is, for all intents and purposes, invisible. It is currently occupying the ‘Waiting for Review’ column, a place where momentum goes to die and where quality begins its slow, agonizing fermentation into technical debt.

I was stuck in an elevator for 27 minutes yesterday. It wasn’t one of those high-speed glass boxes with a view of the city; it was a cramped, utilitarian freight lift that smelled of industrial floor wax and old grease. The stillness in that box was heavy. For the first 7 minutes, I checked my watch. By the 17th minute, I was staring at the rivets in the door, wondering if they were rated for the weight they were currently supporting. The air grew thick, not because it was actually running out, but because the lack of progress makes the mind manufacture its own suffocating atmosphere. Software delivery feels exactly like that elevator. We talk about ‘velocity’ as if we’re racing Ferraris, but most of our time is spent sitting between floors, staring at the rivets of a Jira ticket, waiting for someone to press a button.

Lucas J.P., our machine calibration specialist, stopped by my desk while I was still vibrating from the claustrophobia of the lift. He’s the kind of man who measures his life in microns and 7-decimal precisions. He looked at my screen, saw the ‘2 days ago’ timestamp on my pending review, and grunted. ‘You know,’ he said, leaning back and wiping a smear of graphite from his thumb, ‘if I leave a high-precision spindle sitting in a dormant state for more than 47 hours without a rotation cycle, the lubricant starts to pool. The thermal equilibrium shifts. By the time you turn it back on, it’s not the same machine you turned off. Your code is the same. It’s pooling. It’s losing its heat.’

He’s right, though I’d never admit it to a man who still carries a slide rule in his pocket for ’emergency calculations.’ We treat code as a static asset, a block of stone that stays the same until we chip away at it. But code is actually a liquid state of intent. When I write a fix, I am in a specific headspace. I understand the 77 different ways that the memory management could fail. I have the context of the upstream API and the downstream consumer. But as that code sits in a queue, waiting for a senior architect who is currently trapped in 7 back-to-back meetings, that context evaporates.

By the time the reviewer finally opens the PR 3 days later, my intent has blurred. They ask a question-a valid one-but I have to spend 27 minutes re-reading my own work just to remember why I chose a particular abstraction. This is the ‘waiting problem’ in its purest form. We blame the ‘quality’ when a bug slips through after a long delay, but the bug didn’t happen because the engineer was bad. The bug happened because the feedback loop was so elongated that the developer was essentially a stranger to their own logic by the time the critique arrived.

This isn’t a minor friction; it’s a systemic collapse. We have built entire industries around the idea of ‘Quality Assurance’ as a separate phase, a gate that code must pass through. We imagine this gate improves things. In reality, every hour a ticket spends waiting for QA is an hour where the probability of a ‘rushed fix’ increases. When the release deadline looms and the code has been sitting in the QA queue for 117 hours, the pressure to ‘just get it out’ becomes a physical weight. We compress the actual testing time to compensate for the waiting time. We aren’t sacrificing quality for speed; we are sacrificing quality for the *illusion* of a process.

I’ve watched this play out in 7 different companies over the last decade. The pattern is always the same. Management notices a spike in production incidents. Their reaction? Add more approvals. Add another layer of review. Add a ‘Quality Stakeholder’ meeting every Tuesday at 10:07 AM. They think they are building a dam to stop the flood of bugs. What they are actually doing is building a series of stagnant ponds. Stagnant water breeds mosquitoes; stagnant code breeds regressions.

If you want to fix quality, you have to fix the flow. You have to treat every minute of ‘waiting’ as a critical failure of the system. I told Lucas J.P. about this, and he just laughed. He told me about a calibration job he did on a 47-ton press. The operators were complaining about a 7-millimeter deviation in the final stamp. They thought the mold was warped. Lucas spent 17 hours watching the line and realized the mold was fine. The problem was that the metal sheets were being left on the cooling rack for 7 minutes too long because the guy moving them was also responsible for signing off on the shipping manifests. The metal was getting too cold to take the shape of the mold. The quality problem was a logistics problem.

Software is no different. When we partner with external teams or bring in consultants, the first thing we look at is usually their technical stack. We should be looking at their handoff latency. Choosing to hire dedicated development team fintechisn’t about buying more hands; it’s about buying back the time lost to these invisible queues. It’s about ensuring that when a developer finishes a task, the next person in the chain is already there, ready to catch the baton while it’s still warm. If the baton gets cold, you’ve already lost the race, no matter how fast your sprinters are.

I remember a project where we had 27 developers and only 7 testers. The ‘waiting’ was baked into the math. At any given time, there were 47 tickets sitting in ‘Ready for Test.’ The developers, bored of waiting, would start new tickets. This increased the ‘Work in Progress’ (WIP), which in turn increased the complexity of the eventual merges, which led to more bugs, which led to more QA time. It was a self-perpetuating cycle of failure. We didn’t need better testers. We needed to stop the developers from starting new work. We needed to make the ‘waiting’ visible and painful.

I once tried an experiment in a previous role. I suggested that for every day a PR sat unreviewed, the person responsible for the review had to put $7 in a jar. People hated it. They called it ‘punitive’ and ‘counter-productive.’ But for 17 days, we had the fastest review cycles in the history of the company. It wasn’t about the money; it was about the fact that for the first time, the cost of the wait was tangible. It was no longer a ‘silent’ delay. It was a loud, clinking reminder that time was being wasted.

We often ignore the psychological toll of the queue. There is a specific kind of lethargy that sets in when you know your work won’t be looked at for 77 hours. You start to care less about the small details. You think, ‘Well, the reviewer will catch it,’ or ‘I’ll fix the formatting later.’ You stop being a craftsman and start being a factory worker moving parts down a broken belt. This erosion of pride is the most expensive part of the waiting problem. You can’t measure it in a Jira report, but you can feel it in the office air. It feels like that elevator-dim, cramped, and going nowhere.

Lucas J.P. came back by my desk later that afternoon. He was carrying a sensor that had been crushed by a 700-pound actuator. ‘Someone didn’t wait for the sync signal,’ he said, tossing the mangled metal onto my desk. I looked at it and then back at my screen. My PR was still there. 2 days and 7 hours. I realized then that I was the actuator, and the code was the sensor. If I forced the merge now just to meet the deadline, I’d be crushing the very thing I was trying to build. But if I waited another 37 hours, the context would be so cold that the ‘sync signal’ wouldn’t matter anyway.

We need to stop talking about quality as a checklist and start talking about it as a function of time. Quality is the byproduct of high-fidelity communication and rapid feedback. It is what happens when the gap between ‘I have an idea’ and ‘the system has the idea’ is minimized. Every approval gate, every manual handoff, and every ‘management review’ that doesn’t add direct technical value is just a place where quality goes to evaporate.

I’m still thinking about those 27 minutes in the elevator. The most frustrating part wasn’t the darkness or the smell; it was the fact that I could hear the building continuing around me. I could hear people talking in the hallway on the other side of the door. I could hear the world moving, while I was suspended in a state of ‘in-between.’ Your code feels the same way. The market is moving. Your competitors are moving. Your customers’ needs are evolving. And your fix-your brilliant, 107-line fix-is suspended in the shaft, waiting for a technician who is too busy fixing other elevators to realize that the one I’m in is stuck.

Maybe the solution isn’t more engineers. Maybe it’s not more QA. Maybe the solution is to look at the ‘Wait Time’ column with the same horror we reserve for a production outage. Because a production outage is just a waiting problem that finally ran out of patience. If we don’t value the flow, we will never achieve the quality we claim to care about. I eventually got out of that lift when a maintenance guy hit a reset switch on the 7th floor. He didn’t even apologize. He just said, ‘Sometimes the sensors get confused if you don’t keep things moving.’

I think I’ll go find the person who needs to review my code and sit in their office until they hit the reset switch. It’s better than waiting for the air to get thin. We have 177 tests passing on the local build, and the sun is going down. It’s time to move the metal before it gets too cold to shape. The rivets are starting to look far too interesting, and I’ve had enough of being stuck in the dark.