{/* Delete this post once you’ve written a real one — or keep it as your intro. */}
Most of what I’ve learned as an engineer came from other people writing things down. Not documentation — postmortems, design docs shared publicly, and blog posts where someone explained why an obvious-looking decision turned out to be wrong.
This is my attempt at paying that back.
What I’ll write about#
Architecture decisions and their consequences. The interesting part isn’t the diagram, it’s what happened six months later.
Debugging stories. Specifically the ones where the bug wasn’t where I thought it was.
Things I got wrong. These tend to be more useful than the successes, and they’re rarer online because they’re harder to publish.
Occasionally, the meta-work — how I review code, how I decide what to build, how I think about technical debt as a budget rather than a moral failing.
What I won’t write#
Tutorials that duplicate the official docs. Hot takes about frameworks. Anything where I’d be summarising something I read rather than something I did.
A note on frequency#
I’d rather publish something considered once a month than something thin every week. If that suits you, there’s an RSS feed.
If you’d like to talk about any of this — or about working together — I’m at febriantarigan.dev@gmail.com.