Most skills pages are a list of everything the author has ever touched, which tells you nothing. This one is organised by how deep I actually go, because that’s the part that matters if you’re deciding whether to talk to me.
Where I go deep#
These are the areas I’d be comfortable being interviewed on, designing in, or being the person a team escalates to.
Cloud and distributed systems. Designing and operating services built for cloud environments rather than lifted into them — Azure primarily. Service boundaries, asynchronous and event-driven design, failure-mode analysis, and the resilience patterns that go with them: retry budgets, backpressure, circuit breaking, graceful degradation. A lot of this is knowing which failures to design for and which to accept.
Data engineering. Batch and streaming ingestion, schema design and evolution, validation and quarantine patterns, backfill and reprocessing, late-arriving and out-of-order data. Also the operational side — the seam between applications and pipelines is where the expensive incidents live.
Observability and reliability. Instrumentation with OpenTelemetry, tracing across service boundaries, metric design and the cardinality tradeoffs that come with it, SLI and SLO definition, and alert design that optimises for actionability rather than coverage. Incident investigation and post-incident review.
Languages. Java, Python, and SQL. Java is where I have the deepest and longest-running experience, including the JVM’s concurrency model and the operational behaviour of long-lived services. Python and SQL are what I reach for day to day.
Where I work regularly#
Areas I’m effective in and use often, without claiming the same depth.
AI-enabled software. Building product features on top of language models: retrieval design, chunking and embedding strategy, grounding and citation, and the evaluation problem when there’s no labelled ground truth. The engineering around the model is the interesting part; I’m not a research engineer.
Delivery and automation. CI/CD pipeline design in GitHub Actions, infrastructure as code, automated testing in the deployment path, feature flags and progressive rollout. Most of my interest here is in feedback loops — slow pipelines change team behaviour, not just cycle time.
Architecture and technical direction. Design documents, architecture decision records, technical review, and mentoring. Decomposition and consistency-model tradeoffs.
Where I’m functional#
Enough to be useful, not enough to lead.
Frontend. I build internal tools, dashboards, and review interfaces — HTML, CSS, JavaScript, and consuming APIs. I care about semantic markup and keyboard accessibility. I would not take a frontend-leaning role.
If any of this is relevant to a conversation you’re having, the case study and the blog show the thinking behind it better than a list can. Or just get in touch.