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, entering directly into the second year and studying alongside the job throughout. The marks and the rest of it are on the work history, which also shows the practice behind the writing. I write here about engineering practice, architecture, and the reasoning behind decisions, and the archive is the front door.
If anything here resonates, write. I read everything.