Starting to Write in Public
On writing about infrastructure, systems, and engineering decisions in a way that stays true long after the tools change.
Every developer I admire seems to write. Not because they have all the answers, but because writing forces them to confront what they don’t know yet.
I’ve spent the last few years building things. Servers that serve. Pipelines that ship. Systems that don’t fall over at 2am. Along the way, I’ve learned things…real things, hard-won things, and then I’ve quietly forgotten most of them. Not the concepts. The texture of them. The specific decisions. The tradeoffs that felt obvious only after I burned an afternoon figuring them out. This site is my attempt to stop losing that.
What I actually want to build here
There’s a kind of technical writing I find genuinely useful, and it’s rare. Not tutorials that go stale in six months. Not “10 best practices” posts that could have been written by anyone, about anything, at any time.
What I’m after is something more like load-bearing writing—articles that explain the why behind infrastructure patterns, architectural decisions, and engineering tradeoffs in a way that stays true even as the specific tools change. Content you can return to and still build on. Foundations, not footnotes.
What I’ll write about
This is roughly what’s in my head right now:
- Infrastructure: homelab setups, cloud platforms, Kubernetes, Terraform, Ansible. The things I wish were documented when I was up at midnight searching.
- Backend engineering: software design patterns, SOLID principles, system architecture, API design. The reasoning behind decisions, not just the decisions.
- DevOps: CI/CD pipelines, container security, GitOps. The practitioner’s view, written by someone still in the trenches.
- Learning journey: the honest version of switching into software from another field. What worked, what was hard, what I’d do differently.
Why publicly?
I’m writing to clarify my thinking, meaning that if I can’t explain something in plain text, I don’t understand it as well as I think.
A post I write today might help someone in three years, or remind me in three years why I made a decision. Writing that lives publicly has a chance to compound in a way that a note in Obsidian never does.
I’m also not trying to perform expertise. I’ll write from where I am, about what I’m actually figuring out. “Here’s what I learned solving X” is more useful and honest than a polished LinkedIn post.
A commitment
I’m not promising a posting schedule. I’ll write when I have something worth saying. But I’m committing to finishing drafts instead of letting them rot.
If you found this and something resonates, feel free to email me. I read everything.
— Kimsang