Engineering approach
How I build software and data systems
Practical choices, explicit assumptions, and over fifteen years of engineering systems that people can understand and maintain.
From population health data linkage in Perth and Native Title land administration in the Pilbara, to municipal infrastructure pipelines at the Greater London Authority and bushfire exposure modelling in Tasmania, the common factor has always been disciplined execution over unnecessary complexity.
Start with the problem, not the tool
I work across spatial data, engineering software and web delivery. The common thread is making complicated inputs and processes easier to use, repeat and maintain. A useful solution does not need the largest stack.
Back decisions with evidence and sensitivity testing
I prefer technical decisions supported by benchmarks, sensitivity analysis, and explicit parameters rather than intuition. Testing how an analytical model or calculation engine responds to boundary conditions reveals edge cases before code reaches production.
Use AI assistance with engineering checks
I use AI-assisted workflows for planning, implementation support and review. I keep changes bounded, inspect diffs, and test the outputs. Generated code is a proposal to evaluate, not evidence that a system is correct.
Treat data preparation as engineering
Remote-sensing and machine-learning work includes downloading imagery, cleaning data, supporting labelling, preparing inputs, running inference and checking spatial outputs. I distinguish that contribution from developing new model architectures.
Connect open source, open data, open standards, and open contribution
Open software alone is not enough to guarantee reliable spatial systems. I treat open source (inspectable code and algorithms), open data (reusable datasets with clear licensing), open standards (interoperable formats such as GeoParquet, COG, and STAC), and open contribution (improving shared community datasets upstream) as four interconnected parts of a responsible engineering practice.
Measure before scaling
Tools such as xarray and Dask support lazy and parallel Earth-observation processing. DuckDB, PostgreSQL and PostGIS serve different analytical and storage needs. Chunking, query plans, indexing and memory use deserve measurement rather than assumptions about speed.
Maintain data provenance and audit trails
Every production dataset should have a clear lineage. I use manifest files, cryptographic checksums, and deterministic schemas so intermediate outputs can be audited, verified, and rerun consistently.
Make delivery repeatable
Versioned environments, automated tests, CI/CD and clear release steps are part of the work, not an optional cleanup. A handover should explain how to run the system, what it depends on, and how to recognise a failed or incomplete result.
Treat documentation and reporting as engineering outputs
Executive summaries, data dictionaries, map packages, and clear limitation statements are just as critical as the processing pipeline itself. Technical accuracy only creates value when clients and end users can understand and trust the results.
Make boundaries explicit
Data provenance, access permissions, authentication and deployment configuration need deliberate choices. I favour clear interfaces, least-privilege access and documented limitations over broad claims that a system is secure or compliant.
JetBrains tools are my main development environment, with VS Code as a secondary option. The editor matters less than a reliable loop of implementation, debugging, tests and review.
See selected work