A reflection on repeated production issues, misunderstood tools, and why documenting fixes isn’t the same as addressing root causes. Using pipe cutters as a metaphor, this piece explores how tool literacy—and the lack of it—shapes risk, responsibility, and decision-making in software systems.
Some of the best advice I’ve received lately about knowing when something—or someone—won’t make the cut is this:
When you keep explaining the same thing, and it keeps producing the same questions.
I may have butchered that phrasing, but the idea stuck.
I’ve had a few experiences in the physical world that permanently changed how I think about tools—and how dangerous it is to underestimate them.
Years ago, I worked in Farmingdale, Long Island. The commute alone was unforgettable—bus to train, train to Metro-North, bike from the station. Five hours round trip. I was young, motivated, and ready to grind.
The job was at a printing company that did large-scale marketing runs. One day, I was told I’d be working on a Heidelberg printing press. I’d never seen anything like it. The machine was bigger than my bedroom at the time.
I was given a quick introduction and then left alone.
To this day, I barely remember working near that machine. Maybe it was connected to a massive air compressor—maybe not. What I do remember is this: I didn’t need to understand its full complexity to know it demanded respect.
Most tools are dangerous. What makes them less so—in the words of Flynn from Tron—is the users. More specifically, informed users.
This morning, a production issue resurfaced. It smelled exactly like the last time it happened. The difference this time was that I had documentation—commands, vocabulary, a solution write-up. I applied the same fix, and it worked. Again.
There’s no company newsletter shout-out that fixes the real issue.
I’d already documented this. I’d already explained the root cause. And yet, I was asked—again—to re-document what already existed. Not to deepen understanding. Just to make things feel safe.
Documentation starts as a way for me to be confident in what I’m working on. But official documentation is supposed to make the organization safer. When it becomes a loop instead of a learning tool, it’s no different than repeatedly explaining something to someone who refuses to understand it.
That’s not communication. That’s avoidance.
Which brings me to pipe cutters.
Over the years, I’ve slowly collected every pipe cutter I need to work on my home. It cost money—but more importantly, it cost time and attention. Pipe size matters. Material matters. Copper, PVC, PEX—each comes with its own vocabulary, techniques, and gotchas. None of this happened overnight.
Each tool exists because using the wrong one creates damage.
Software and cloud infrastructure work the same way. Except now, the constraints are higher, the blast radius is larger, and the systems remember your mistakes.
If you don’t understand the statefulness of an Elastic cluster, you’ll propose solutions that don’t align with reality. If you don’t understand the tool, you’ll keep asking for a different one—while cutting the same pipe incorrectly over and over.
Before we talk about new solutions, we should make sure we’re holding the right cutter.