Yet Another Blog About How I Became a Developer

"You don't have to be a genius to become a coder. You just have to be consistent."

I don't remember the exact moment when I became interested in computers. What I do remember is that, at some point, a computer stopped being just a machine sitting on a desk and became something I wanted to understand. That distinction changed quite a lot of things.

When I first encountered computers, I didn't know how they worked. I didn't know what programming was. I didn't know what an operating system did, what a compiler was, or why typing strange words into a black window could somehow make a machine do something. Honestly, I didn't even know how to turn one on properly.

And yet, somehow, I ended up becoming a developer.

There was no grand plan

I didn't sit down one day and decide that I was going to become a software engineer. There wasn't a roadmap. There wasn't a carefully designed five-year plan. There was just curiosity.

I wanted to know how things worked, and once I learned one thing, there was always another thing hiding behind it. You learn what a computer is. Then you want to know how programs work. Then you want to know how programs talk to the operating system. Then you want to know how the internet works. Then you want to build something that uses the internet. Then you discover databases. Then servers. Then APIs. Then suddenly you're debugging something at two in the morning and wondering how you got there.

That's probably one of the strange things about technology. There is always another layer.

The first time code actually did something

There is something special about the first time you make a computer do something because of a piece of code you wrote. It doesn't have to be impressive. It can be a tiny program. A simple calculation. A button that changes something on a screen. A little game. A script that saves you five minutes of repetitive work. It doesn't matter.

The important part is the realization:

I told the machine what to do, and it listened.

That feeling is difficult to explain to someone who has never experienced it. The machine doesn't care who you are. It doesn't care whether you're good at mathematics. It doesn't care whether you think you're smart. It simply follows the instructions. If the instructions are wrong, it fails. And if you understand the problem well enough to give it the right instructions, it works.

There is something beautifully honest about that.

Learning to get stuck

One of the most important things I learned while becoming a developer wasn't a programming language. It was learning how to be stuck.

Because you get stuck a lot. You write something. It doesn't work. You read it again. It still doesn't work. You stare at the screen. You change something. Now it fails in a completely different way. You search for the error. You find three Stack Overflow answers, two GitHub issues and a blog post from 2014 that somehow solves exactly your problem. You try the solution. It doesn't work. You try another one. Eventually, after hours of fighting with it, you discover that you missed a single character. And then it works.

That process can be frustrating. But eventually you realize something important:

Being stuck doesn't mean you're bad at programming.

Being stuck is programming.

The illusion that everyone else knows more

When you're learning, it's very easy to believe that everyone around you understands everything. They don't. Some people simply know more about the particular thing you're currently struggling with. That's all.

There will always be someone who knows more than you. There will also always be something you know that someone else doesn't. The mistake is comparing your entire journey with somebody else's highlight reel. You see someone building an impressive application and forget that they probably spent years learning the things that now look obvious. You see someone writing code quickly and assume they must understand everything. They probably don't.

Experienced developers aren't people who never get confused. They're people who have become comfortable with confusion. They know that eventually the pieces will fit together.

Consistency

There is a sentence I keep coming back to:

You don't have to be a genius to become a coder. You just have to be consistent.

I don't mean that intelligence doesn't matter. Of course it does. But programming is not a competition to see who can remember the most syntax. You don't need to remember every function. You don't need to know every framework. You don't need to understand every computer science paper ever written.

You need to keep learning. You need to keep trying. You need to be willing to open the documentation again. You need to be willing to admit that you don't understand something. And, perhaps most importantly, you need to keep building.

A little bit every day compounds. One small concept leads to another. One project teaches you something that the previous project couldn't. One mistake becomes useful the next time you encounter a similar problem. Years later, you look back and realize that you didn't become better through one enormous breakthrough. You became better through hundreds of small ones.

Tutorials can only take you so far

When you're starting out, tutorials feel like the answer to everything. Follow the steps. Type the code. Get the result. Move to the next tutorial. It feels like progress. And sometimes it is.

But there comes a point where the tutorial ends. Nobody tells you what to type next. That's when learning really begins.

Because building something yourself is different. You have to decide what the problem actually is. You have to decide how to structure the application. You have to choose technologies. You have to make mistakes. You have to change your mind. You have to throw away code you spent hours writing. You have to search for things you thought you already understood.

And eventually, you have something that is yours. It may not be perfect. It may not even be particularly good. But you built it. That matters.

Software is more than code

The longer I work with software, the less I think of programming as simply writing code. Code is only one part of it. There is understanding the problem. There is designing the solution. There is deciding what not to build. There is thinking about the person who will use the software. There is maintaining something you wrote months ago. There is reading somebody else's code. There is naming things properly. There is figuring out why something is slow. There is deciding whether a problem deserves a sophisticated solution or a boring one.

And sometimes the best engineering decision is the least interesting one. I've learned to appreciate that.

Good software often disappears into the background. When it works well, nobody thinks about the machinery underneath. They simply use it. That simplicity is usually not accidental. There is often a considerable amount of work hiding behind something that feels effortless.

The things I wish I knew earlier

If I could go back and talk to the person who was just beginning, I wouldn't give him a list of programming languages to learn. I'd tell him a few other things.

You don't need to know everything before you start. You never will. Start anyway.

You will forget things. That's normal. Even experienced developers look things up. Knowing how to find the answer is often more useful than memorizing the answer.

Don't be afraid of documentation. Documentation can look intimidating when you're new. Eventually, it becomes one of your best friends.

Build things. Not because every project needs to become a startup. Build because making something forces you to understand things differently.

Don't be afraid to delete your code. Sometimes the best version of a program is the one you write after throwing away the first version.

Learn the fundamentals. Frameworks change. Libraries disappear. Languages evolve. The fundamentals tend to stay. Understand how computers work. Understand data. Understand algorithms. Understand networks. Understand systems. Understand why things work, not just which command makes them work.

And don't confuse complexity with expertise. Writing complicated code doesn't make you a better developer. Often, making something simpler is harder.

Why am I writing this?

Which brings me to this blog.

I have spent a lot of time building things. Some worked. Some didn't. Some were abandoned. Some taught me more than I expected. There are things I know now that I couldn't have imagined knowing when I started. And there are still an enormous number of things I don't know. That's okay.

I don't want this blog to pretend otherwise. I don't want it to be a collection of carefully polished opinions written from some imaginary mountain of knowledge. I'd rather use it as a record — a place where I can write about things I'm learning, things I'm building, things I get wrong, things I change my mind about, ideas that seem obvious today but took me years to understand.

Maybe some of those things will be useful to somebody else. Maybe somebody starting out will read one of these posts and realize that being confused is perfectly normal. Maybe I'll read these posts years from now and laugh at some of the things I believed. That would be useful too.

There is still a long way to go

The funny thing about becoming a developer is that the more you learn, the larger the unknown becomes. At the beginning, you think there are perhaps a hundred things you need to learn. Then you learn those hundred things and discover ten thousand more. Eventually, you stop trying to finish learning. You just keep going.

There are still technologies I haven't touched. There are systems I don't understand. There are problems I've never encountered. There are things I haven't built yet. And that's probably the best part. There is still room for curiosity. There is still something new around the corner.

So, this is another blog

Yes. There are already millions of blogs on the internet. There are thousands of articles explaining programming. There are probably hundreds explaining whatever I decide to write about next. So why write another one?

Because nobody else can write my version of the journey. And perhaps that's enough of a reason.

This isn't meant to be the definitive guide to software engineering. It isn't meant to prove anything. It's simply a place to put some thoughts down — a small record of things learned, things built, things broken and things understood a little better than before.

Maybe someone will find something useful here. Maybe I will. Either way, I'm going to keep writing. I'm going to keep building. I'm going to keep learning. And after all these years, I still don't know exactly where this road is going.

But that's alright. I didn't have a map when I started either.

The best is yet to come.