How I Got Into Software Engineering

How I Got Into Software Engineering

I’ve been a professional developer for about four years now. Before that, I finished a Bachelor’s in Health Science - not the typical path into tech, but career changes happen.

The Health Science Detour

The health science degree wasn’t wasted time. I learned research methodology, data interpretation, and how to read academic papers critically. Healthcare also exposed me to the gap between how things should work in theory and how they work when real humans are involved. That perspective shows up in how I approach software - skepticism about perfect plans, attention to edge cases, awareness that users don’t always do what you expect.

But I wasn’t going to become a clinician. Somewhere in the middle of that degree, I started teaching myself to code. Initially it was just curiosity - I wanted to understand how the tools I used worked. Then I started building small things. Then I realised this was what I actually wanted to do.

Learning Without a CS Degree

I’m mostly self-taught, which has shaped how I think about learning. Without a curriculum telling me what to study next, I learned by need: I’d hit a problem, figure out the minimum required to solve it, then move on. This is efficient for getting things done but leaves gaps. I might understand React’s rendering model but have fuzzy knowledge of how TCP handshakes work.

Good mentors helped a lot. Early on, I worked with developers who’d been doing this for decades. They’d point out when I was reinventing wheels, suggest better approaches, and recommend books that actually mattered. I owe a lot to people who took time to explain things properly instead of just telling me to Google it.

I picked up certificates along the way - Azure Fundamentals, various Coursera courses - but the real education was building things. There’s a type of understanding you only get when something breaks at 2am and you have to figure out why.

Now I’m working on a Master’s in IT at Deakin. It’s not about the credential so much as filling in the gaps in my self-taught knowledge. Formal study covers things I wouldn’t have chosen to learn - algorithm analysis, database theory, formal specification - and some of it turns out to be useful.

What I Work On Day to Day

Full-stack development is the broad label, which really means “a bit of everything.” Frontend with TypeScript and Vue or React. Backend with Node.js or Go. Databases, usually PostgreSQL or cloud options like Firestore. CI/CD pipelines, infrastructure as code, cloud deployments on Azure and AWS. The specifics change per project, but the common thread is moving between layers of the stack as needed.

Some projects that shaped how I work:

Game server auto-scaling - A system that spun up and down game servers based on player demand. This pushed me below the application layer into Linux internals, networking, and VM orchestration. Before this project, I thought of servers as magic boxes that ran my code. After, I had a much better mental model of what’s actually happening underneath.

3D model capture app - An Android app using ML-based pose detection to capture images for 3D body modeling. First time on a mobile platform, first time with on-device machine learning. The constraints were different from web development - battery life matters, network isn’t reliable, and you’re dealing with hardware (cameras, sensors) in ways web apps don’t.

Healthcare data pipeline - Automated extraction of patient data from PDFs, de-identification for research compliance, and automated reporting. Taught me a lot about working with messy real-world data and thinking carefully about privacy.

Lots of web applications - Business sites, internal tools, customer portals. Less technically exotic than the projects above, but equally important for learning how to ship things that people actually use, handle feedback, and maintain code over time.

How I Think About the Work

The thing I keep coming back to is whether what I build actually helps the person using it. Not in a abstract “user-centred design” way, but concretely: can they do what they need to do? Do they get stuck? Do they have to contact support because something’s confusing?

Code quality matters, but it’s in service of this goal. Clean code is easier to change when users tell you something doesn’t work. Good test coverage gives you confidence to fix things without breaking other things. Documentation helps the next developer (or future you) understand why things are the way they are.

I’ve seen technically impressive systems that failed because no one thought carefully about the humans who had to use them. I’ve seen simple, even ugly code that worked great because it did exactly what users needed. I’d rather build the second type.

The Current State

Four years in, I’m still learning constantly. The field moves fast - new frameworks, new cloud services, new paradigms. Some of it matters, some of it is noise. Getting better at distinguishing which is which.

I work with other developers, designers, product people, and stakeholders. I’m better at collaboration than I was when I started. Better at taking feedback, explaining technical constraints in non-technical terms, and understanding that my job is solving business problems, not just writing code.

The reason I started writing these posts is to document what I’m learning. Partly for myself - writing clarifies thinking, and having a record helps me see how my understanding has changed. Partly for anyone else on a similar path. The career changers, the self-taught developers, the people figuring it out as they go.

If you’re one of those people: it’s possible. It takes time and work, but it’s possible.