Learning, Building and Sadly, Too Often `function`

I write code.

Sometimes it works.

Sometimes it works after three hours of asking myself why it doesn't work.

And sometimes, after staring at the same error for long enough, I discover that the problem was a missing semicolon, a typo, or something I somehow managed to overlook for the past two hours.

This is probably one of the more interesting things about learning software development.

You start by thinking that programming is about learning a language. Then you learn a framework. Then another one. Then you discover that there are about seventeen different ways to build the same thing and suddenly you're questioning every decision you've ever made.

For me, the journey has been a combination of learning, building, experimenting and, sadly, writing a lot of function.

Learning

When I first became interested in technology, there was something exciting about being able to make a computer do something simply by writing instructions.

You write some code, run it, and something happens.

That feeling never really gets old.

The problem is that the more you learn, the more you realise how much you don't know.

You learn HTML and discover CSS.

You learn CSS and discover that making something look good on different screen sizes is another problem entirely.

Then JavaScript enters the picture.

Then frameworks.

Then Git.

Then APIs.

Then databases.

Then deployment.

And somewhere along the way, you realise that learning software development isn't really a destination.

There is always something else.

A new tool.

A new concept.

A different approach to an old problem.

At the moment, I'm particularly interested in frontend development and data science, and I'm still figuring out exactly where those interests will take me.

For now, I'm enjoying the process of finding out.

Building

Learning something is one thing.

Actually building with it is another.

I've found that some concepts make perfect sense while reading about them and suddenly become confusing the moment I try to use them in a project.

That's why I have been trying to spend more time building.

Small projects.

Experiments.

Things that may or may not ever make it to production.

The important part is that they give me something to work through.

When you're building something yourself, you start asking different questions.

Why isn't this working?

Why is this API returning that?

Why does it look perfect on my laptop and completely broken somewhere else?

Why did changing one line break three other things?

And, occasionally:

Why did I write this?

Those moments are frustrating, but they are also where a lot of the learning happens.

Breaking Things

I think breaking things is an underrated part of learning.

Not intentionally, of course.

Although sometimes intentionally too.

There is something useful about making a mistake and having to figure out what happened.

You begin to understand your tools differently.

You become more careful about assumptions.

You learn to read error messages instead of immediately searching the entire error on Google.

You learn that sometimes the answer is in the documentation.

And sometimes the answer is a very obvious mistake you should have noticed five minutes ago.

Either way, you learn.

The function Problem

Then there is JavaScript.

A language that can make you feel extremely clever one minute and completely confused the next.

There is something almost amusing about how many times the word function can appear in a project.

Functions inside functions.

Functions returning functions.

Functions that take functions.

And eventually, you start wondering whether everything is just a function wearing a different outfit.

But beyond the jokes, learning JavaScript has taught me something useful: understanding a language is more than memorising syntax.

It's about understanding how the language behaves.

Why something works.

Why something doesn't.

What happens behind the scenes.

And how to write code that someone else can actually understand.

I'm still learning that part.

More Than Code

One thing I am beginning to realise is that becoming a developer isn't only about becoming technically good.

There is also communication.

There is collaboration.

There is asking questions.

There is being able to explain what you're trying to do.

There is reading someone else's code and trying to understand what they were thinking.

There is receiving feedback and resisting the urge to immediately defend every line of code you've written.

There is also learning how to search properly.

This may sound trivial, but knowing how to find the right information is an important skill when you're learning technology.

You can't know everything.

You don't need to.

You just need to be willing to find out.

What Comes Next?

I don't have everything figured out.

I don't think I am supposed to.

Right now, I'm interested in learning more, building more things and getting better at solving problems.

Some projects will work.

Some won't.

Some code will probably be rewritten several times.

And there will almost certainly be more function.

But that's part of the process.

I'm learning.

I'm building.

I'm breaking things.

I'm fixing them.

And, sadly, I'm writing a lot of function.

Maybe that's not such a bad place to be.