About Me

I fix things other people gave up on.

I'm Steve Hill, a senior software engineer based in the UK. I've been writing code professionally since 2006, but I started much earlier — typing out BASIC listings from magazines on a rubber-keyed Spectrum, loading programs from cassette tapes, and trying to understand how the machine actually worked. That curiosity never went away.

I specialise in rescue work. The neglected Rails monolith nobody wants to touch. The infrastructure migration the team has been putting off for two years. The upgrade path that looks impossible until someone sits down and maps it out. I've done this at Resource Guru, where I work full-time, and across freelance engagements where I've inherited systems in various states of disrepair and made them maintainable again.

I stayed technical on purpose. Twenty years in and I'm still an IC — not because I couldn't do something else, but because I want to be in the code. I'd rather understand a system than manage a team that understands it for me.

I pick languages to fit the problem. Rails for web applications, Swift for iOS, Rust for systems work, assembly when I want to understand the hardware. I've written production code in all of them. The common thread isn't a stack — it's wanting to use the right tool and understand it properly.

When I make a case for a technical direction, I write it down. Risk matrices, trade-offs, alternatives considered. I've changed infrastructure decisions with a 60-page position paper that would have been lost if it stayed in someone's head. Writing is how I think, and it's how I make sure the reasoning outlasts the conversation.

Outside of client work, I run Code Like It's 198x, an education platform teaching assembly language through building games on the Commodore 64, ZX Spectrum, NES, and Amiga. I'm also writing cycle-accurate CPU emulators for those systems. It's the kind of work where getting one instruction wrong means the whole screen tears — and that's exactly why I enjoy it.

I write about what I learn. Engineering principles, architecture trade-offs, and why boring technology usually wins. If any of that sounds useful, have a look around.