Most of my data work starts and ends in scripts.
I’ll pull something from an API, normalize it, maybe run a quick transformation, and dump the result as Markdown or plain text. That’s usually enough — until someone outside the engineering loop needs to look at it.
That’s where things get awkward.
The friction point
A common situation for me:
I generate a Markdown summary from a script
The content is technically correct
The receiver is not technical
They don’t want raw Markdown. They don’t want code blocks. They just want something they can open, read, and maybe paste into another system.
At this point, the output is correct, but the format is wrong.
Why I don’t “fix” this properly
Yes, I could:
Extend the script to export multiple formats
Add a conversion step
Build a reusable exporter
But that assumes this will happen again in the same way.
Usually it won’t.
This kind of request is sporadic:
A one-off report
A temporary data explanation
Something generated just to answer a question
I’ve learned that forcing structure here creates more work than it saves.
What I actually needed
The requirement was extremely limited:
Take Markdown output
Turn it into something more neutral (HTML / clean text)
Don’t store anything
Don’t introduce new tooling
I wasn’t looking for a “best solution”. I just wanted the data to move from my environment to someone else’s without friction.
Using a disposable step
For these cases, I sometimes insert a very small, temporary step between “script output” and “final delivery”.
When converting Markdown-heavy output, I’ve used this page before:
I treat it the same way I treat an online formatter or validator:
Open
Paste
Convert
Close
No attachment to it beyond that moment.
Why this works in practice
From an engineering perspective, this approach has one advantage:
it doesn’t pretend to be part of the system.
There’s no configuration, no dependency, no expectation of reuse. It’s just a bridge that exists long enough for the data to cross formats.
That matters, because the moment you formalize a temporary workaround, you’ve already over-engineered it.
Where I would not use this
This is not something I’d rely on for:
Automated pipelines
Repeated reporting
Audited or versioned data
If the output matters long-term, it deserves a proper implementation.
But for short-lived data artifacts, the goal isn’t perfection — it’s clarity.
Closing thought
A lot of developer workflows break down not because the logic is wrong, but because the output reaches a different audience.
When that happens, I try to resist the instinct to “build a solution” and instead look for the fastest way to translate formats without dragging new complexity into the codebase.
Sometimes, the most engineering-friendly move is knowing when not to engineer.
Top comments (0)