When I started learning to code, I thought the formula was pretty straightforward:
"Learn to code → build cool projects → get a job → become a developer."
Simple. Cute, even.
Three years later, I have a slightly different formula:
"Learn to code → build projects → apply for jobs → get rejected → question your life choices → learn something new → meet someone → apply again → get rejected differently → somehow get a job → discover the stack has changed → learn something new → repeat."
And honestly? I wouldn't trade the experience.
Three years in tech has taught me things I don't think I could have learned from a course, tutorial, bootcamp or YouTube video.
It's about staying curious, being adaptable, communicating with people, dealing with rejection, understanding business, building relationships and somehow keeping up while the entire industry changes underneath your feet.
1. Getting a tech job is a skill on its own
This was probably one of the biggest surprises for me. You can spend months learning JavaScript, React, TypeScript, Git, APIs and whatever else is currently sitting in your “things I need to learn” folder… and still struggle to get someone to hire you.
Because knowing how to code and getting someone to give you an opportunity are two different problems.
- Can you explain what you've built?
- Can you show evidence that you're good at it?
- Can you communicate?
- Can someone trust you with their project?
- Do you know anyone who can recommend you?
Eventually, you realize that job hunting isn't simply about being good enough. You also have to learn how to present yourself, find opportunities, communicate your value and put yourself in places where people can actually discover you.
2. Your network matters more than you want to admit
For a long time, I wanted my work to speak for itself. But here's the uncomfortable truth: People also need to know you exist.
You can have a beautiful portfolio sitting quietly on the internet while nobody knows it exists. Meanwhile, someone else might get an opportunity because they happened to know someone who knew someone.
Networking isn't necessarily about collecting hundreds of LinkedIn connections and commenting “Great post! 🔥” on everything someone publishes.
It's about relationships. Sharing what you're building. Helping people when you can. Being curious. And occasionally sending the terrifying message: “Hey, I saw what you're working on. I'd love to connect.”
3. You have to keep learning — but you cannot learn everything
This one is particularly dangerous for developers because technology moves fast.
You learn React. Then there's Next.js. Then TypeScript. Then server components. Then some new framework you've never heard of suddenly has 40,000 GitHub stars. Then AI enters the conversation. Then someone tells you that the thing you spent six months learning is apparently “dead.”
"Can I please finish one tutorial first? 😂"
The solution isn't to learn everything. That's impossible. I've become much more interested in learning how to learn.
4. Your tech stack will probably change
When you're starting out, it's easy to become attached to your stack. You might think: “I'm a React developer.”
Then you discover that companies use different versions of React, different frameworks, different styling systems, different backend technologies, different databases and approximately seventeen different ways of doing the same thing.
Your stack is not your identity. It's a toolbox. The ability to adapt is more valuable than memorising a particular tool.
5. Being a developer isn't just about writing code
When I first got into development, I thought becoming better meant becoming better at code. And obviously, yes.
But eventually your job starts involving things that have nothing to do with whether you can write a map() correctly.
- You have to understand what the client actually wants.
- You have to communicate with people.
- You have to explain technical decisions to non-technical people.
- You have to estimate work.
- You have to debug someone else's code.
- Sometimes you even have to open a spreadsheet.
Nobody warned me about the spreadsheet part. The code is just one of the tools.
6. Rejection doesn't necessarily mean you're bad
Tech has a particularly nasty way of making rejection feel personal.
Sometimes there are things you genuinely need to improve. But rejection doesn't always mean that. There could have been someone with more experience. Someone cheaper. Someone internally referred. The company could have changed its hiring plans.
That's why I've had to learn to separate “I didn't get this opportunity.” from “I'm not capable.” Those are not the same statement.
7. Your portfolio isn't just a gallery
I used to think a portfolio was basically: Here are my projects. Here is my GitHub. Here is my contact information.
But your portfolio is actually part of your argument for why someone should work with you. A project becomes much more interesting when you explain the problem behind it.
Suddenly, you're not just showing code. You're showing problem-solving.
8. You will never feel like you know enough
This might be my favourite lesson. Because tech can make you feel like you're constantly behind.
There's always someone younger. Someone smarter. Someone who knows Rust. Someone who built a startup. Someone contributing to open source.
Three years ago, there were things that felt completely impossible to me that I can now build without thinking too much about them. That doesn't mean I've “made it.” It means my definition of difficult has changed.
9. You don't need to know your entire career path
I thought I needed to figure out exactly what kind of developer I wanted to be. Frontend? Backend? Full-stack? Developer advocate? Freelancer? Founder?
The more experience I get, the less I believe careers work like a straight line. You can explore. You can change your mind.
The important thing is to keep moving. You don't need the entire map. Sometimes you just need the next road.
So, what has three years in tech actually taught me?
That the hardest part isn't always the code. It's staying in the game.
It's learning new tools without convincing yourself that you need to learn every new tool.
And perhaps most importantly: You are allowed to be a work in progress.
I'm finally starting to understand that the goal isn't to eventually reach some magical point where you know everything and never struggle again. The goal is to become someone who can figure things out.
And probably, while I'm writing this, someone somewhere is releasing another JavaScript framework.
"I'll deal with it tomorrow."