Data & Analytics

I work with relational data — Postgres, MySQL, MariaDB — and I've used analysis to drive decisions that had real consequences. Which partnerships were worth pursuing. Which product features to prioritise. Where demand actually was, as opposed to where everyone in the room had assumed it was. That last one comes up more often than it should. The thing I've come to believe about analysis is that it usually fails upstream of the numbers. Not because the query was wrong or the chart misleading, but because nobody asked a question worth answering. It's easy to produce a dashboard that's technically correct and completely inert — everyone looks at it, nobody changes anything. The useful skill isn't building the visualisation. It's knowing which question, if answered, would actually change what someone does on Monday. That framing comes from having sat on the business side. When you've been the person who has to act on an analysis, you get impatient with analysis that doesn't tell you to do anything. What I'm building. Data modelling, warehousing, and the tooling that turns raw output into something a business can act on. Coming at it from an engineering background means I'm comfortable with the pipeline half — the extraction, the transformation, the scheduling, the part where the thing has to run reliably without supervision. Coming at it from the product half means I care about whether anyone uses what comes out the other end. There's a version of data work that's really software engineering wearing a different hat, and that's the version I'm drawn to. Treating pipelines as systems that need to be maintainable, testable, and understandable by the person who inherits them. Not scripts that happen to have worked once. Why it connects to everything else. I'm interested in bio-inspired computing — how natural systems adapt and optimise under conditions they were never designed for. Ant colonies find efficient paths without a central planner. Immune systems classify threats they've never encountered. These are, structurally, data problems solved by systems that had no access to a database. I find that clarifying. It's a reminder that good solutions frequently already exist somewhere, in a form nobody's thought to borrow yet, and that the interesting move is usually recognising the analogy rather than inventing from scratch.