I Didn't Take the Normal Route Into Software

There is a version of becoming a software engineer that looks very neat on paper. Finish school. Go to university. Study computer science. Graduate. Get a junior position. Work your way up.

That wasn't my route.

My route involved bootcamps, tutorials, different programming languages, projects that didn't work, projects that barely worked, long nights trying to understand things I probably should have been taught earlier and a lot of learning by doing.

Learning because I needed to build

The thing that kept me moving was that programming was never just an academic exercise for me. I wanted to make things.

That changes the way you learn. Instead of asking, 'What should I study next?', you start asking, 'What do I need to understand to make this work?'

Sometimes that meant learning databases. Sometimes APIs. Sometimes frontend development. Sometimes deployment. Sometimes spending an entire evening discovering that the problem wasn't where I thought it was.

Every language left something behind

I worked through Ruby on Rails, Python, C#, JavaScript and eventually TypeScript. At the time, moving between technologies could feel like starting again.

It wasn't.

Each stack gave me another way of thinking about software. Rails taught me conventions. Python taught me clarity. C# taught me structure. JavaScript taught me how much could be built across the browser and eventually the whole product.

The technologies changed, but the underlying problems stayed surprisingly similar: How do I model this? How should these systems communicate? What happens when something fails? How do I make this understandable six months from now?

Eventually I stopped chasing languages

There comes a point where learning another framework stops being the thing that will make you better. You need to spend more time actually building.

For me, TypeScript became the centre of that work. React, Node, Next.js and React Native gave me a practical way to work across web, backend and mobile.

But the important part wasn't choosing TypeScript. The important part was finally understanding that the language was a tool. The goal was never to become the person who knows the most syntax. The goal was to become someone who can take an idea and turn it into something people can use.

Real work changed everything

Working on real products forced me to become much less precious about code. A beautiful abstraction doesn't matter if the customer can't complete checkout. A clever component doesn't matter if the page takes forever to load. The newest framework doesn't matter if the team can't maintain it.

That is probably the biggest lesson my unconventional route gave me: software exists for a reason.

The code is important. The thing the code enables is more important.

Why this matters to WebAfro

The way I learned is closely connected to why I built WebAfro. I know what it feels like to figure things out without having every answer handed to you.

That makes me value practical solutions. I don't want to sell businesses technology they don't need simply because I know how to build it.

Sometimes the right answer is a custom application. Sometimes it is Shopify. Sometimes it is WordPress with a good integration. Sometimes it is fixing the system you already have.

Good engineering starts with knowing the difference.

Still learning

Being self-taught doesn't mean you stop learning once you get a job. If anything, it makes the habit harder to switch off.

There is always another system to understand, another production problem to solve, another technology worth evaluating and another mistake waiting to teach you something.

I'm comfortable with that. I don't think I'm finished becoming an engineer.