I recently spent over $35,000 having a bathroom professionally built. New tile, new layout, high-end finishes—the works. I trusted the process and assumed the price tag meant quality. But as I walked across the newly finished floor, something felt… wrong.
Some tiles were slightly higher than others. At first, I chalked it up to “just how tile feels,” but I couldn’t shake the sensation—tiny ridges underfoot, just enough to be annoying. When I asked the contractor about it, they assured me it was “within tolerance” and perfectly normal.
I wasn’t so sure.
So I spent $45 on a digital caliper.
A little bit of online research led me to ANSI A108.02, the standard that governs tile lippage. According to the spec, there are hard numbers that define what’s acceptable and what’s not—especially for rectified (sharp-edged) tiles.
I measured.
I recorded.
And I found that several tiles exceeded the allowable tolerance.
Suddenly, the conversation changed. This wasn’t just a customer complaining about “feel.” This was documented evidence that the job didn’t meet professional standards. That $45 caliper gave me data—and data gave me leverage.
In the end, the contractor acknowledged the issue and agreed to fix it. That one small tool, and a few hours of digging, likely saved me tens of thousands in repairs and rework down the line.
The Bigger Lesson: This Is Exactly What It’s Like to Build Software
It hit me shortly after resolving the bathroom issue: this is the same skillset I rely on in software development.
Every good software engineer I know has a technical toolkit—but the best ones also invest in understanding the domain they’re building for. They don’t just code; they learn the landscape. They ask the right questions. They know when something “feels off,” and they have the tools and vocabulary to validate that instinct.
Whether you’re working in finance, healthcare, e-commerce, or education, there are three constants:
1. A little domain knowledge goes a long way
I didn’t need to be a tile setter. I just needed to understand what “level” meant in a measurable, standards-based way.
Likewise, you don’t need to be a licensed accountant to build financial software—but you do need to understand terms like “accrual,” “reconciliation,” or “GAAP.” That surface-level understanding separates developers who guess from those who deliver.
2. The right tool exposes hidden problems
My caliper made invisible problems visible. In software, that might be a debugger, a test harness, a log analyzer—or even just a spreadsheet that tracks business logic failures over time.
Tools don’t replace intuition. They reinforce it.
3. Standards exist for a reason. Learn them.
ANSI A108.02 might not mean much to most people, but it protected me from thousands in loss.
In software, those standards might be REST conventions, ISO security requirements, accessibility guidelines, or contract-driven API schemas. Knowing the standards of your domain lets you measure your work against something objective—and defend it when it matters.
Invest Small, Gain Big
The $45 I spent on a caliper wasn’t just a purchase—it was an investment in clarity. The same is true in software. Sometimes it’s a book, a whitepaper, an hour with a subject matter expert, or a lunch-and-learn session with someone in operations.
In a world full of complex problems and high stakes, that kind of small up-front investment is how you protect much larger ones.
You don’t need to become an expert in everything.
You just need to know enough to see when something’s not quite right—and what to do next.