"I cannot build in public, my work is proprietary."
This is the most common objection and it is based on a misreading of what people actually read these posts for.
Nobody wants your code
They want the problem and the reasoning.
"We had a job that ran nightly and occasionally ran twice" is not proprietary. Neither is the reason, which was that a retry fired while the original was still running and nothing was holding a lock. Neither is the fix, which was an idempotency key on the logical unit of work rather than on the invocation.
That is a complete, useful post with no company information in it.
What actually cannot be shared
The real list is shorter than people assume:
- Client and customer names, unless cleared
- Internal metrics: revenue, headcount, user numbers
- Unreleased product details
- Security specifics: architecture that would help an attacker, versions of things you run
- Anything identifying a colleague without asking
- Code you do not own
Everything else is usually fine, though check your contract rather than taking that from a blog post.
The generalisation move
Take the specific and move up one level.
We were seeing duplicate charges in the billing reconciliation for Acme Corp when their nightly sync overlapped with our retry window.
becomes
Any scheduled job with retries needs an idempotency key on the work, not on the invocation. We found this the way most people find it, which is by doing the same thing twice.
You lost the client name and the domain. You kept the entire insight, and the generalised version is more useful to more readers.
The thing that makes it better
A constraint you cannot discuss forces you to write about the reasoning instead of the artifact.
Posts that show the code often lean on the code to do the explaining. Posts that cannot show it have to make the argument in prose, which usually means the writer understood it better and the reader gets more.
The best technical writing on the internet is largely people describing problems they cannot demonstrate.
Practical rules
Write it, then remove. Draft with the real details, then take out the names. Trying to write vaguely from the start produces mush.
Wait. A problem from four months ago on a project that shipped is much safer than this week's.
Ask. For anything borderline, one message to whoever owns it. The answer is usually yes and it costs nothing.
Never the security specifics. Even generalised, "our auth had a hole shaped like this" is a bad post while you still run that auth.
And the honest limit
Some jobs really do prohibit this. Defence, some finance, anything with a strict social media policy. Check before assuming you are the exception.
But most people who say they cannot post about their work have not actually read their contract. They have read the phrase "build in public" and assumed it means publishing the repository.
It does not. It means writing about the problem.