The long way round

When you start programming, your first program is usually quite friendly.

It prints “Hello.”

You run it. It works.

And you assume everything else will follow more or less the same pattern.

It's a comforting illusion. 😅

A few months later, you're learning databases, sessions, deployments, customer requirements and that wonderful category of problem: “it worked yesterday.”

I wanted to learn software development. I hadn't realised I was mainly learning how to learn.

A direction, not a perfect plan

My route into computing wasn't linear.

I started studying law before choosing software engineering. That decision came with practical challenges, including finding ways to finance my education.

That change of direction shaped my journey, including the story I share in Back where I started.

When you change direction, you want to know exactly where the new road leads. But “working in IT” doesn't describe one daily routine.

There are websites, mobile apps, business systems, security, infrastructure and many other paths.

At first, you're simply trying to map the territory.

The first big surprise: code isn't enough

Learning the syntax of a language can be relatively quick.

Delivering useful software takes much more.

You must listen to people, clarify requirements, design understandable screens, organise data, secure access, test scenarios and deploy reliably.

And when you work with real users, you need to explain things without making them learn your technical vocabulary.

Someone doesn't ask for better database normalisation.

They ask to find their invoice.

Our job is to connect the need to the technology.

Projects teach in a different way

Work and personal projects have given me a practical learning process.

When something genuinely needs to work, the gaps in your understanding become visible very quickly.

You search, test, fail, read documentation, revisit decisions and ask for help when necessary.

It doesn't replace formal education. It gives it another dimension.

I don't believe you always have to choose between degrees and projects.

Both can matter, and I explore that in The degree or the GitHub repository?.

The temptation to learn everything

Software brings an endless stream of technologies.

A new framework. Another language. A library that promises to simplify everything. And AI tools accelerating the pace.

You can spend more time deciding what to learn than actually building.

I'm trying to start from the problem instead.

Does this project need a mobile app, an API, a particular database? Can an existing tool solve it more simply?

That doesn't mean stopping exploration.

It means giving curiosity some direction.

What matters most to me now

If I had to summarise the useful lessons, I wouldn't list every language I've tried.

I'd talk about habits:

• Understand before copying a solution.
• Be willing to say “I don't know yet.”
• Test failure cases, not only success paths.
• Write software that someone else can maintain.
• Change course when users show that an idea misses their needs.

All of this takes time.

Where is the finish line?

I don't think there is one.

There will always be another unfamiliar problem or tool.

That would be worrying if the job required knowing everything forever.

Thankfully, it doesn't.

I didn't become a developer the day I knew every answer.

I started becoming one when I learned to move forward despite the questions.

There are still plenty of them.