Engineering as Applied Research: Code, Tools, and the Thinking Behind Them
I studied architecture before I wrote software. Years in a studio building models, running simulations, writing code to measure embodied carbon as you design. At the Architectural Association I studied remote sensing and cybernetics. I learnt that design is about organising relationships.
When I moved into engineering, I brought that with me.
Most software writing stops at "here's how I built it." I'm interested in why certain decisions reveal something about the problem itself. What the system teaches you whilst you're building it.
What This Is
This blog is a record of building software, hardware and objects. Currently I am focused on a media organiser I'm developing at Interfacing Research Laboratory. The goal is to intensify relationship to information. Vector search and LLMs are here because the question is: what does it mean to be in closer relationship to what you've collected?
That question shapes every technical decision. How you store data, how you surface connections, what gets abstracted and what stays visible.
I'll also write about the internal tooling we're open-sourcing. Infrastructure meant to keep things legible as they grow.
Posts will cover:
- Architecture decisions and why they matter
- Stack trade-offs
- What failed and what I learnt
- Small experiments with context
- Where design thinking and systems thinking overlap
Some posts will be long. Some will be commit-sized. The format follows the thinking.
Why Public
Writing forces precision. Vague intuitions have to become testable claims. Commits are a curriculum. Your real education is what you build, what you delete, and what you notice when systems behave under load.
I'm writing for people who want to understand how things work and why certain approaches reveal more than others.
Current Questions
- How should LLMs integrate into workflows without abstracting away understanding?
- What makes infrastructure stay legible over time?
- What does "taste" mean in engineering, and can it be articulated?
- How do you build tools that reorganise relationships instead of optimising tasks?
These aren't rhetorical. They're what I'm actively working through.
The Long Game
Engineering is about building systems you can still understand six months later. Systems that reveal their logic under pressure. Systems where the complexity makes sense because you can trace it back through the decisions.
This blog is that trace.