A portfolio tells you what someone shipped. It is a list of outcomes with the uncertainty edited out. Every project reads like it was planned that way from the start, which is almost never how it happened.
This is where the uncertainty goes.
What this is
Field notes from production. Specific problems, how they were investigated, what the data actually said, and what changed afterwards. Some of it will be long — queueing behaviour and database internals do not compress well. Some of it will be short: one symptom, one root cause, one lesson.
What it will not be: tutorials copied from documentation, or confident claims about systems I have not operated.
Why write it down
Three reasons, in increasing order of honesty.
The first is that writing an incident down forces the explanation to be complete. A theory that survives in your head rarely survives a paragraph. If I cannot explain why latency moved, I did not find the cause — I found a correlation I liked.
The second is that most of what I know came from other engineers writing things down. Mailing list threads, postmortems, the occasional furious blog post about a database. That debt is worth paying forward.
The third is that a green dashboard is not proof that anything works:
# Proof of liveness, not proof of correctness.
curl -fsS https://example.com/health && echo "ship it"That command tells you one process answered one request. It says nothing about the replica that is twelve minutes behind, the connection pool that saturates at peak, or the backup that has never been restored. The gap between “the check passed” and “the system is healthy” is most of my job, and most of what there is to write about.
What to expect here
The topics follow the work:
- PostgreSQL reliability — replication, recovery, and query performance under load
- Kubernetes and cloud infrastructure, including the parts that are genuinely not worth adopting
- Networking and traffic interception, where the packet rarely goes where the diagram says
- Observability, latency measurement, and why percentiles mislead under concurrency
- Incidents, and the operational habits that make the next one shorter
Longer pieces get a full investigation. Shorter ones — production notes — get a problem, a cause, and a fix.
A standing disclaimer
Nothing here includes customer data, credentials, or architecture that belongs to an employer. The interesting part of an incident is almost always the reasoning, and reasoning generalises without naming anyone.
See you in the logs.