20 years have passed since I got paid to code for the first time. Here are few things I’ve learned along the way.
Most programmers think a career grows with time.
Get a job. Complete projects. Stay long enough. Become senior.
I did that. I worked on around 100 projects, became a team lead, moved to Norway, and arrived confident that my experience would open every door.
Then I discovered I was a junior developer with five years of bad habits.
That was painful. It was also one of the best things that happened to my career.
After around 20 years in tech, more than 200 projects, a move from washing cars to leading AI work, and a few career disasters in between, here is what I would tell my younger self.
Your programming career is not your job.
It is the skills, systems, relationships, reputation, and judgment you build that no employer can take away.
1. My first job came from trust, not technical skill
My first coding job paid around 250$ a month, around1.5 an hour.
That was double what I earned washing cars, so I felt like I had won the lottery.
The money mattered, of course. But what mattered more was that programming gave me a way out of being replaceable.
Growing up, I saw only how to depend on one employer |
|
My father was treated badly at work because he did not play politics. At one of my early jobs, a boss took ten percent of my salary just to remind me that other people were waiting to take my place.
Few weeks later I heard my landlord tell his boss, “No, I am busy.”
|
That stayed with me. I wanted the kind of skill where saying no did not mean being hungry. I wanted choice, “freedom” if there is such thing.
Anyway, I started learning programming whenever I could. I read printed books between car washes. The only online thing I had related to the industry was an online forum.
Good times.
But I kept showing up on the forum, even became a forum administrator, built trust, and eventually someone who had seen my work asked me to help with real projects.
That led to my first full-time web development job.
But before programming, I worked in a café through high school, talking to all kinds of people. That taught me how to listen, calm people down, read the room, and handle difficult conversations. This was important, as later, even as the youngest developer in the company, I was the one talking to clients and project managers.
That created leadership opportunities long before I was ready for them.
My first attempt at leadership was terrible. I pushed people, acted like a jerk, and confused being loud with being useful.
Later, I learned the job was not to push people harder, but to remove remove blockers for them.
If you are early in your career, help people before you need something from them. Answer questions. Share useful work. Be the person who follows through.
People hire skills. But they trust people.
2. Even one hundred projects can still leave you with weak fundamentals
For years, I worked on websites at a very fast pace. We built around one a week, and I ended up with roughly 100 projects on my CV.
That sounds impressive.
It was also the perfect illusion.
When I moved to Norway, I had the projects, the team-lead title, and plenty of confidence. Then I joined a company where we had to maintain one application for years.
The system changed. Requirements changed. The code needed to evolve.
And my code did not like that at all.
I did not understand object-oriented programming properly. I could not refactor without breaking something else. I had built tightly coupled code for years, and I blamed clients, changing requirements, and management.
The uncomfortable part was simpler.
I had avoided learning the fundamentals because familiar work kept coming.
I was not a senior developer, but a junior with five years of bad habits.
This is why project count is a dangerous metric. Ten similar projects may teach you less than one difficult system that forces you to understand architecture, testing, debugging, security, and trade-offs.
Projects open doors.
Fundamentals get you hired.
It took time... |
|
When I started applying for new jobs in Norway, I learned this the hard way. I could talk about my 100 projects, but when interviews went deeper, there was not much depth to show. It took failed interviews, and deliberate learning to rebuild that foundation. |
So audit of your own experience and see what you have:
Ask yourself:
- What problems can I solve without copying an answer?
- What parts of a system do I avoid touching?
- Can I explain why this architecture exists?
- Can I debug an issue when the error message is useless?
- Do I know the tools I use, or only the steps I repeat?
- Your gaps are not proof that you failed.
They are the map.
3. Comfort feels like progress right before it stops being progress
I have had several jobs that felt like the best job ever!
....
