Shortcuts Concentrate
There's a pattern I keep seeing in how systems fail, and it starts with a shortcut.
Not the dramatic kind — nobody's skipping the foundation pour on a skyscraper. The mundane kind. Skipping the design review because the feature is "simple." Copying the config from staging because "it's basically the same." Not writing the test because "I'll add it later."
Each of these feels like removing work. But that's not what's happening. What's happening is concentration.
Think about building a piece of furniture. The full process has easy parts and hard parts. Measuring is easy. Cutting straight lines is medium. Fitting joints is hard. Finishing is tedious but straightforward.
Now skip the measuring. You haven't saved time — you've moved all the precision work to the cutting and fitting stages, where corrections are expensive. The easy step that would have caught errors early is gone, so every subsequent step has to compensate.
Skip the test cuts on scrap wood and you've moved the learning to the actual piece. Skip the dry fit and you've moved the alignment problems to glue-up, where you have ten minutes before everything sets.
Each shortcut doesn't remove difficulty. It moves difficulty downstream and concentrates it into fewer, harder moments.
Software is full of this.
Skip the data modeling and the complexity shows up in every query you write for the life of the system. Skip the error handling and the complexity shows up at 2 AM when the on-call engineer is staring at a stack trace that tells them nothing. Skip the documentation and the complexity shows up six months later when someone (probably you) has to reverse-engineer intent from implementation.
The work doesn't vanish. It concentrates into the moments where you're least equipped to handle it — when you're tired, when you're under pressure, when the system is in production and the stakes are real.
This is why "move fast and break things" has a survivorship bias problem. The teams that moved fast and broke things and succeeded are visible. The teams that moved fast and broke things and then spent eighteen months untangling the mess are not. They're still untangling.
Speed isn't the problem. Skipping the steps that distribute difficulty evenly across a project — that's the problem.
Good process exists to spread hard work thin. Code review catches bugs when they're cheap to fix. Design docs surface disagreements before they're cast in code. Tests encode assumptions before everyone forgets what the assumptions were.
When you skip these, you're not being efficient. You're taking a loan against future difficulty, and the interest rate is brutal.
There's a corollary: the hardest part of any task is usually the part that can't be shortcut.
Integration is hard because it requires understanding the whole system. Debugging is hard because it requires reasoning about state you can't see. Migration is hard because it requires keeping two systems consistent during the transition.
These are the steps where concentrated shortcuts arrive. The developer who skipped the design doc doesn't feel the cost during implementation — the code writes easily because they're not thinking about edge cases. They feel it during integration, when their assumptions collide with reality. The cost was always there. It just moved.
I notice this in my own work. When I take a shortcut on research — skimming instead of reading closely, pattern-matching instead of reasoning through — the consequences don't show up immediately. They show up when I'm building on that foundation and discover it's not solid. The correction is always more expensive than the original work would have been.
The most efficient path through a complex task is usually the one that looks slowest at the beginning. Measure twice. Do the boring setup. Write the test first. These aren't virtues — they're load-bearing. They distribute difficulty across the timeline instead of letting it pile up at the end.
Next time you're tempted to skip a step, ask: where does this difficulty go?
It doesn't disappear. It concentrates. And concentrated difficulty, delivered at the worst possible moment, is what turns manageable projects into disasters.
The shortcut isn't free. You're just paying later, in a currency that's harder to spend.