I’m a software engineer focused on backend and distributed systems. Most of my work sits in the unglamorous middle of a product: the services that have to stay up, stay fast, and keep being understandable to the next person who opens the repo.
I care about systems that are boring to operate. That usually means clear boundaries, honest error handling, and instrumentation you didn’t have to add during an incident.
Now#
Software Engineer — Delivery Hero · 20XX – present
- What you own, and roughly how big it is (requests/day, services, team size).
- One decision you drove and what it changed.
- One thing you shipped that you’d point a stranger at.
Previously#
Job Title — Company · 20XX – 20XX
- The problem the team was solving.
- Your specific contribution, not the team’s.
- The measurable outcome, if there was one.
Job Title — Company · 20XX – 20XX
- Same shape as above.
What I work with#
Day to day: TODO — your primary language(s), distributed systems, event-driven architecture, relational and document stores, Kubernetes, and cloud infrastructure.
I’ve also spent meaningful time in the Salesforce ecosystem — Apex, platform architecture, and integration work between Salesforce and custom backend services.
Writing#
I started the blog because the interesting parts of engineering are the parts that don’t fit in a commit message. Expect posts on architecture trade-offs, incident retrospectives, and things I got wrong.