When I finished Northcoders in 2022, I think I imagined becoming a software engineer as a fairly neat transition. Learn to code, get the job, become an engineer.
The reality has been much more interesting than that.
Getting the first job was only the beginning
Northcoders gave me full-stack foundations and, more importantly, enough confidence to make a career change. My first engineering role at GS Systems meant turning those foundations into commercial software: React Native, React, AWS, real users, deadlines and code that had to keep working after I stopped looking at it.
That shift from learning exercises to production was bigger than I expected. Suddenly the question wasn’t just whether I could make something work. It was whether somebody else could understand it, whether it behaved properly when the happy path disappeared, and whether I could come back to it weeks later and still make sense of the decisions I’d made.
From there I moved into fintech at ThinkMoney. For a while my work leaned more heavily towards frontend and mobile, but that period taught me a huge amount about product quality, releases, accessibility, design systems and the responsibility that comes with building software people depend on.
Growing across the stack
My current role has pulled me much further across the stack: backend services, APIs, SQL, AWS, event-driven systems and Rust, alongside the frontend work I already knew. That has been challenging at times, but it has also made something clear to me: I don’t want to be defined by one layer of an application.
I like being able to follow a feature from the person using it, through the API and data, into the infrastructure that keeps it running. I also like asking why we are building it in the first place.
That has changed how I approach problems. I’m less interested in immediately reaching for an implementation and more interested in understanding the shape of the problem first: what the user needs, what the data is telling us, where the risk sits and what the simplest useful version actually looks like. The code matters, but so does everything around it.
Four years in
Four years in, I’m taking on broader problems, working across more of the stack and thinking much more about the decisions around the code — not just the implementation. There’s still plenty I want to learn, but I’m increasingly comfortable owning work, asking difficult questions and helping shape the direction as well as the delivery.
That feels like a pretty good place to be.
The biggest change is probably that I no longer think progress means knowing everything. It means asking better questions, understanding more of the system around me, communicating clearly, owning the work I do and being willing to change my mind when I learn something new.
Four years ago I was trying to become a software engineer. Now I’m much more interested in what kind of engineer I want to become next.