I'm a software developer at Smedley Group Advanced Technology, a global electric karting events company with operations in the UK and the US. I'm part of a small engineering team reporting to the Head of Advanced Technology. Small enough that every project means owning the problem end-to-end: understanding the domain, designing the system, deploying it, keeping it running.
The domain is motorsport; the discipline applies beyond it. What defines the work is less the technology stack and more the environment it demands. Every project begins with a domain I'm still learning, stakeholders with different mental models of the problem, and constraints that only surface once you start asking the right questions. The software comes after all of that.
I think carefully about engineering practice and whether it's producing real value. I'm sceptical of process adopted by convention rather than by reasoning, and I believe every architectural decision should have a rationale you can articulate clearly. If it doesn't, it isn't a decision; it's a default.
That instinct, understanding before building, isn't always the path of least resistance. When timelines feel short and stakeholders want visible progress, investing time in understanding the problem correctly can look like delay. I've found the rework cost of building the wrong thing consistently exceeds the cost of understanding it first, but I know that's a case I have to make in context, not a given I can take as read.
Outside the day job, I recently finished a BSc in Computer Science at the University of East Anglia, graduating with First-Class Honours and a first in every module I took. I was awarded the BCS Prize for the best individual performance by a BSc Computing student. I write here about engineering practice, architecture, and the reasoning behind decisions. The archive is the front door, and the work history shows the practice behind it.
If anything here resonates, write. I read everything.