Engineering Across Layers
Modern software rarely belongs to one discipline. These pages document the different areas that influence how I design and build technology, along with the projects where I have applied them.
One system, several disciplines
The boundaries between disciplines are where many failures begin.
A feature can be correct in the browser and wrong in the ledger. A permission can exist in the interface and be absent from the API. An application can pass its tests and fail behind a reverse proxy. I work across those boundaries because the user experiences the whole system.
Each area below connects to products and writing that show how I have used it. The pages describe engineering decisions and their limits, rather than a list of tools I have touched.
Software engineering
Most of what I know about software engineering I learned by keeping software running after it shipped. These are the choices I make and where I made them.
Applied in 5 projects
Read about software engineeringSystems architecture
A systems architect decides where the boundaries go, and writes down what each boundary costs. These are the principles I apply, the trade-offs I accept, and the checks I run before a design is allowed to become code.
Applied in 6 projects
Read about systems architectureEnterprise software
Enterprise software is mostly about boundaries: who may do what, to whose data, and how anyone can later prove what happened.
Applied in 4 projects
Read about enterprise softwareForward deployed engineering
Specifications rarely describe an organisation perfectly. The real process lives in spreadsheets, habits and the way one person always does a task. I use the term forward deployed engineering for a way of working, not for a job title I have held.
Applied in 4 projects
Read about forward deployed engineeringAI and automation
I add a model to a system when it removes real work, and I design the system so it still behaves sensibly when the model is wrong or absent.
Applied in 2 projects
Read about ai and automationDevOps
A feature is not finished until someone else can install it, recover it from a bad day and find out when it breaks.
Applied in 3 projects
Read about devopsNetworking
Many bugs that look like application bugs are network facts: a name that resolves differently inside a container, a proxy that rewrites a header, a cookie the browser refuses to store.
Applied in 3 projects
Read about networkingCybersecurity engineering
I approach security as part of how a system is built: who is allowed, how that is checked, what is recorded and what happens when one layer is wrong. I do not hold penetration-testing or other security certifications, and this page does not imply that I do.
Applied in 5 projects
Read about cybersecurity engineeringInfrastructure
I like infrastructure that one person can understand end to end. I run my own, and that is how I learn what breaks.
Applied in 3 projects
Read about infrastructureProduct engineering
Product engineering is deciding what the software should do, and just as often what it should not do yet.
Applied in 5 projects
Read about product engineering