I didn’t plan to deal with unit conversion that day.
I was reviewing a small batch of mechanical specs pulled from a supplier’s PDF — nothing fancy, just dimensions that needed to be checked before pushing the data into a script that generates internal documentation.
The problem was simple:
the source used millimeters, while our docs and calculations downstream expected centimeters.
Normally, this kind of thing disappears inside a preprocessing step or gets handled by code. But this wasn’t a clean dataset — it was a mix of copied tables, handwritten notes, and values scattered across a few documents.
At that point, writing a script felt heavier than the task itself.
The Awkward Middle Ground Between “Do It Properly” and “Just Finish It”
As engineers, we like clean solutions.
But there’s a category of work that lives in an uncomfortable middle:
Too small to automate properly
Too repetitive to do entirely in your head
Too risky to eyeball and move on
This was one of those cases.
I needed to sanity-check a handful of values quickly before committing them to anything permanent. Opening a spreadsheet, setting formulas, exporting — all of that would’ve taken longer than the actual review.
So I treated it the same way I treat quick format checks or timestamp conversions:
a temporary step in the workflow, not a system.
A Small Detour That Didn’t Need to Become a Tool Choice
The key constraint for me in moments like this is mental overhead.
I don’t want to:
evaluate tools
compare features
remember what I used last time
I just want to convert a few numbers, verify they look right, and move on.
That’s when I used a simple mm-to-cm conversion page (mmtocm.net
) as a scratchpad step — not something to adopt, bookmark, or standardize, but something to unblock the task in front of me.
No setup, no decision-making. Convert, confirm, close the tab.
Why This Matters More Than the Conversion Itself
The interesting part isn’t the conversion.
It’s where it fits in the workflow.
In real-world engineering and development work, a lot of tasks aren’t worth formalizing. They exist in the gaps between systems:
validating numbers before committing them
checking assumptions during review
translating units while reading someone else’s documentation
These steps don’t need robust tooling.
They need low-friction, disposable solutions.
Once the data passed the check, the rest of the workflow went back to being code-driven and repeatable — exactly where it should be.
Treating Temporary Steps as Temporary
I think there’s value in recognizing which parts of your process deserve structure, and which don’t.
Not everything needs:
a library
a script
a permanent place in the stack
Some things just need to work once, correctly, and get out of the way.
For me, this was one of those moments — a quick conversion during a documentation check that didn’t justify anything more elaborate.
And once it was done, it disappeared from the workflow entirely, which is probably the best outcome you can ask for.
Top comments (0)