Systems are everywhere. The question is whether you can see them.

Orientation

I am a Philosophy, Politics, and Economics student at the University of Southampton. I am also a software engineer. These are not two separate identities — they are two modes of the same underlying interest: how do complex systems behave, and what can be built to understand or influence them?

I am drawn to problems that exist at the edges of conventional categorisation — where economic reasoning intersects with geopolitical reality, where philosophy clarifies what engineering obscures, and where software can operationalise what theory can only describe.

Why PPE

Philosophy

Philosophy teaches clarity. More specifically, it teaches you to notice when a question is confused — when apparent disagreement is actually a semantic dispute, when a claim is empirical that presents itself as conceptual, when a framework is producing bad outputs because its foundations are quietly broken. This is not merely academic. It is a debugging skill for reasoning.

Politics

Politics, studied properly, is a study of institutions, power, and incentive structures. It asks why states behave as they do, how international orders are maintained and disrupted, what conditions produce cooperation or conflict, and how institutional design shapes individual behaviour in ways that aggregate to collective outcomes. These are systems questions — they just happen to involve humans and governments rather than code.

Economics

Economics provides the most rigorous vocabulary for reasoning about tradeoffs, incentives, and equilibria. Its modelling tools — game theory, mechanism design, general equilibrium analysis — translate naturally into questions about any system where actors make choices under constraints. It also forces precision: in economics, vague reasoning is quickly exposed by formal structure.

Why Software Engineering

A theory that cannot be implemented is a theory that cannot be fully tested. Software engineering is the discipline of turning ideas into systems that interact with reality — and reality has a way of exposing assumptions that survive perfectly well in the abstract.

I am particularly drawn to systems-level work: authentication architectures, rendering pipelines, low-level JVM injection, data ingestion pipelines, market modelling. These problems reward the same kind of thinking that good analytical philosophy rewards — precision about state, clear reasoning about edge cases, attention to what is explicitly defined versus what is assumed.

The act of building a system teaches you things about it that description alone cannot. When a model fails at the implementation stage, that is not an engineering problem — it is a conceptual one. The code is just honest about it.

The Synthesis

Political and economic systems can be modelled, analysed, visualised, simulated, and in some cases operationalised. The tools that allow this are software tools. A researcher who understands both the substantive domain and the technical infrastructure can do things that neither a pure social scientist nor a pure engineer can.

This is the operating premise of most of my project work. Peacemetrics is not a visualisation exercise — it is an attempt to make the implicit weighting systems in geopolitical analysis explicit and configurable. The Bazaar Tracker is not a scraping project — it is an application of market microstructure reasoning to a constrained but real economic environment.

The combination of PPE and engineering does not produce a generalist. It produces someone who can reason rigorously about complex systems and then build tools to investigate them.

Technical Philosophy

I have a strong preference for understanding systems from the inside. When I work with a piece of technology, I want to know how it works at the level below the abstraction I am using. This is partly epistemic — I distrust abstractions I cannot see through — and partly practical. Edge cases live at the level below the documentation.

I am willing to engage with problems that most engineers avoid because the success probability is unclear. Reverse engineering obfuscated bytecode. Building custom rendering pipelines from scratch. Extracting predictive signal from noisy time-series data. These problems are difficult precisely because they require reasoning under uncertainty without a clear path — which is, not coincidentally, the condition under which most important problems exist.

I prefer explicit systems over clever ones. If something is difficult to understand in retrospect, it was probably not well-reasoned at the time.

Outside the Work

I take urban photography seriously as a practice of observation — the same quality of attention that makes a geopolitical analysis sharp also makes a photograph honest. I read broadly: political science, economic history, philosophy of mind, cliodynamics, technical theory. I am genuinely interested in the long run: what happens to institutions over centuries, how civilisations accumulate and lose the capacity to sustain themselves, and what it would take to detect those transitions early.