Skills
Table of Contents
On this page I tried to provide a snapshot of my tools and practices: the Earth observation data I work with and how I go about it, the infrastructure I run things on, how I work with teams, and the language I write it all in.
- Data & geospatial
- STAC · Zarr / GeoZarr · Icechunk · TiTiler & eoAPI
- How I work & teams
- ADRs before code · dry runs and canaries · in-depth reviews · runbooks · workshops
- Infrastructure
- Kubernetes · Argo Workflows & Events · Flux & Helm · Terraform · GitHub Actions
- Python
- uv · ruff · pyright · pytest · FastAPI · Xarray
🗺️ Geospatial data engineering #
In oceanography I processed data from gliders, moorings, research ships and satellite altimetry, and published some of the results as open datasets. The problems carry over to Earth observation almost unchanged. You still need quality control and metadata that a stranger can understand, only now the data lives in object storage and the formats have to let people read just the part they need.
- Formats & catalogues
- STAC · Zarr v3 · GeoZarr · Icechunk · HEALPix · NetCDF
- Services
- TiTiler · eoAPI
Ocean data then, Earth observation now
- Formats
- Ocean: NetCDF, HDF5
Earth observation: STAC, Zarr, cloud-optimized geospatial formats - Processing
- Ocean: time-series and spectral analysis, gridding, quality control, uncertainty quantification
Earth observation: data pipelines - Scale
- Ocean: ocean model output and reanalyses, plus 140,000+ quality-controlled profiles merged from 13 databases
Earth observation: terabyte-scale satellite archives - Metadata
- Ocean: CF conventions, standardized vocabularies, documented datasets with DOIs
Earth observation: STAC catalogs, data-model version recorded in each item - Quality
- Ocean: calibration of moored CTD sensors against ship casts, sensor intercalibration, automatic and manual QC
Earth observation: STAC validation before publishing, GeoZarr conformance checks across readers (GDAL, TiTiler, OpenLayers)
🧭 How I work #
A good part of my job doesn’t show on the commit graph: working out what to build before building it, and how to change a system people already depend on without breaking it.
- Architecture decisions
- Architecture decision records and MVP breakdowns written before the code, with open questions left explicit for the team
- Capacity & data layout
- Capacity plans from measured throughput; chunk and shard layouts chosen from read benchmarks on the live data
- Standards
- STAC, Zarr/GeoZarr and CF conventions
- Releases & versioning
- Automated semantic releases and pinned versions; the data-model version recorded in the catalogue; each data release tied to a tagged snapshot
- Production changes
- Dry runs and canaries before full production runs, run limits enforced inside the tool, and an undo path rehearsed before the big runs
- Working with coding agents
- Coding agents for exploring code, investigating and reviewing; changes are not shipped until I can explain them; adversarial agents to challenge and test architecture design and decisions
🏗️ Infrastructure & DevOps #
I discovered DevOps practices out of necessity: managing research data across multiple environments taught me that manual processes don’t scale, and inconsistency often leads to problems. Now I find myself gravitating toward automation not just for efficiency and repeatability but because it forces clarity in thinking. “If you can’t automate it, you probably don’t understand it well enough yet.”
- Orchestration
- Kubernetes (OVH/OpenStack) · Argo Workflows (batch pipelines) · Argo Events (data-driven triggers) → data-driven Earth observation pipelines
- CI/CD
- GitHub Actions · Conventional Commits (GitLab CI previously) → automated, reproducible releases
- GitOps & IaC
- Flux (GitOps reconciliation) · Helm (packaging) · Terraform (multi-environment) → declarative multi-environment deployments
- Containers
- Docker · multi-stage builds · Chainguard · minimal base images
- Security
- Prowler · Trivy · zizmor · SHA-pinned actions · Dependabot · Keycloak/OIDC → supply-chain and platform hardening
- Observability
- Grafana · Loki · Prometheus · Falco → catching silent failures early
- AWS
- boto3 · AWS CDK constructs · Lambda functions
My experience with cloud infrastructure has taught me to appreciate both the technical challenges of system design and the practical impact these systems have on development teams. Container security emerged as a natural extension of my infrastructure work when I began focusing on platform reliability and team productivity. Working with minimal base images has shown me that security practices can actually simplify operations: fewer vulnerabilities mean less time spent on patches and more predictable deployment cycles.
👥 Team leadership & enablement #
The greatest good you can do for another is not just share your riches, but reveal to them their own.
Now, at Development Seed
- Reviewing colleagues’ and partners’ pull requests in depth before release
- Writing runbooks and playbooks the team can reuse, for example on container hardening and on registering datacube releases
- Helping run eoAPI + STAC workshops
Earlier, at DWP (2022–2025): mentored four junior engineers · onboarding guides · test coverage from 10% to 85%
- Mentored four junior engineers through pair programming and knowledge sharing
- Regular debugging sessions that became teaching moments
- Wrote onboarding guides for new team members
- Created reusable Terraform modules and Docker templates encoding best practices
- Raised test coverage from 10% to 85% on two production web apps
- Implemented pre-commit hooks and CI/CD standards balancing guidance with flexibility
Earlier, in research (2010–2021): trained PhD students · OSNAP cruises with teams of 10+ · peer review for JGR Oceans and GRL
- Helped train PhD students and research staff in computational methods
- Helped plan and run OSNAP mooring cruises with international teams of 10+ people
- Mentored Master’s students on research cruises and their thesis projects
- Contributed to the OceanGliders water-transformation task team
- Reviewed papers for JGR Oceans and Geophysical Research Letters, and research proposals
Learning Through Collaboration: Some of my most valuable moments happen when working alongside my teammates on challenging problems. Those debugging sessions often become mutual learning experiences where we both discover better approaches to error handling and system design.
Freedom Through Structure: I’ve found it interesting how clear technical guidelines can actually increase creativity. When the team doesn’t have to worry about formatting or basic quality checks, I think it creates more mental space to focus on solving the actual problems at hand.
From Solving to Enabling: I shifted my way of thinking from “I know how to fix this” to “How can we build systems so this problem becomes easier for everyone to solve?”
🐍 Python #
I transitioned to Python as my primary language in 2020 after extensive work with MATLAB in research. What began as exploratory data analysis for oceanographic datasets has evolved into building production Flask applications, maintaining reusable Python packages and implementing comprehensive testing frameworks. I’ve found that each domain I worked in taught me something different about writing maintainable, reliable code.
- Tooling
- uv · ruff · pyright · pre-commit hooks
- Analysis
- NumPy · Pandas · Xarray
- Testing
- pytest · integration testing · mocking strategies
- Web frameworks
- Flask · Django · FastAPI
- Visualization
- Matplotlib · Plotly · Cartopy (geospatial) · Folium
- ML & statistics
- scikit-learn · statistical modeling · Monte Carlo methods
- Documentation
- Sphinx · MkDocs · automated API docs
🎯 My technical evolution #
The diagram below shows how I understand my professional development, with Problem Solving as “the driving force”.
I like the idea of representing my career evolution into three different branches: Scientific Thinking from research years where I learnt to be systematic and question everything, Engineering Practices developed transitioning to software development, and Team Leadership , the area I think I am growing most, as I found sharing knowledge often more impactful than individual work. I think these areas reinforce each other: my research background helps me approach infrastructure methodically, engineering experience makes me a better mentor, and team work drives more systematic thinking.
The Continuous Learning foundation seems also to me essential, it is thanks to this that I have been able to developed these three branches, through my various role changes, technologies I learnt, or conversations I had with my colleagues. I think it is the way I approach growth: staying curious, building on what I know, and helping others grow too.
Problem solving
Scientific thinking
systematic · rigorous · data-driven
Engineering practices
automation · security · scalability
Team leadership
mentoring · pairing · standards
Continuous learning
What I’m currently focussing on
- Knowledge Sharing: Contributing to documentation and learning resources for geospatial data engineering
- Open Source Participation: Engaging with communities building Earth observation infrastructure
- Science to Software: Turning scientific data and methods into tools and datasets other people use, from glider and mooring toolboxes in my oceanography years to analysis-ready satellite datacubes today