Problem. Most engineering writing is either too abstract to use or too specific to reuse. I want to write the kind that sits in between: real problems from real systems, written up so someone else can act on them.
What this site is
A working notebook, published. Every post comes from something I actually had to debug, design, or ship — cloud architecture, distributed systems, and the messy reality of getting AI assistance to help rather than hallucinate.
The format
Each post follows the same four-part shape:
- Problem — what broke and why it mattered
- Diagnosis — how I narrowed it down, including the dead ends
- Fix — the change itself, with code or config
- Lessons — what I would do differently next time
The constraint I set myself: if a competent engineer outside this project cannot follow it, the post is not finished.
Why publish at all
Two reasons. First, writing forces me to check whether I actually understand something or just got it working by accident. Second, the answers to these problems were hard to find when I hit them — if this saves one person a weekend, it earned its keep.
The site is built with Hugo and published from GitHub, so the source of every post lives in a repository I control. If this platform ever disappears, the content does not.