20 years of coding, from washing cars to leading AI adoption

20 years of coding, from washing cars to leading AI adoption

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. Your first job comes from trust, not just 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 what it meant to depend completely 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. 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.

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 time, 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 I had ever had.

That is usually when I needed to pay attention because a stable job can be good. Familiar systems can be good. Knowing the people and the product can be good.

But familiarity is not the same as growth.

When you know every system, every process, and every person, work becomes easier. You can solve problems before they happen. You know which meeting will be useless before it starts.

That feels like seniority.

Sometimes it is but sometimes you are just repeating the same year of experience five times.

A career should add weight to the bar. It should give you new problems, new environments, and new people who make you better.

If you are always the smartest person in the room, you are on the wrong train.

This does not mean you need to change jobs every two years because someone on LinkedIn made a colourful chart about it. I am obviously not a rocket surgeon.

It means you need a next challenge.

That challenge might be a new role, a harder project, a conference talk, a side project, mentoring someone, or learning a skill your current job does not require.

Do not wait for your employer to design your growth plan.

They might. But your career is too important to leave there.

4. Offer value before you ask for more

For a long time, I thought salary growth came from asking at the right time.

It does not.

You can negotiate better when you have made your value visible.

At one job, I asked for more responsibility and an eight percent salary increase. My manager looked at me as if I had asked for his house keys.

Later, I got a new manager who gave me a 15 percent increase without me asking. Why?

I ACTIVELY made his job easier, on purpose.

I did not bring him every small problem. I prepared. I followed through. I solved things. He could focus on bigger issues because he trusted me with mine.

That changed how I looked at value.

Do not show up to a salary conversation with a vague feeling that you work hard. Most people work hard.

Show the impact.

Even keep a bragging document. Every month, write down one useful thing you did:

  • A problem you solved.
  • A risk you prevented.
  • A process you improved.
  • A client or stakeholder you helped.
  • A difficult situation you handled well.
  • A skill you learned and applied.

When the time comes to ask for more responsibility, a promotion, or a salary increase, you are not trying to remember what happened six months ago.

You have the evidence.

Visible impact becomes career leverage.

5. Professionalism is mostly invisible preparation

Later in my career, I worked with consultants from McKinsey, Capgemini, and similar companies.

At first, I thought they were simply smarter than everybody else.

Then I noticed something.

They came into meetings prepared.

They knew why the meeting existed. They understood what had happened before. They had thought through objections. They knew which decision they wanted, who needed to own the next step, and what happened if plan A failed.

They often had plan B already.

The visible part was confidence.

The invisible part was preparation.

This changed how I work.

Professionalism is not just replying to emails and arriving on time. That is the entry ticket.

Professionalism is making it easy for other people to move forward.

Before an important meeting, ask:

  • What is the purpose?
  • What decision do we need?
  • Who needs to be involved?
  • What objections will come up?
  • What is the next step, owner, and deadline?
  • What happens if this plan fails?

You do not need to become a consultant with a 70-slide presentation for every conversation.

Nobody wants that.

But when you prepare one step ahead, people notice. They trust you with bigger things because you make work feel less chaotic.

The real project was me

Today, I work with AI across technology, people, processes, and business needs.

I do not see programming as less important because of that. My technical background is exactly what helps me ask better questions about security, product value, implementation, and risk.

But coding alone was never the whole career.

The people who create opportunities are the ones who can connect the technical work to real problems. They communicate. They prepare. They learn in public. They help others. They understand that a system is more than files and functions.

Over the years, I lost money, changed countries, found out my skills were weaker than I thought, failed interviews, started again, changed direction, and rebuilt more than once.

A job can disappear.

A title can disappear.

A project count can turn out to mean very little.

But the skills you deliberately build stay with you.

Treat yourself as your most important project.

Build fundamentals. Learn to communicate. Keep notes. Track your wins. Make useful work visible. Find people who are better than you. Take on challenges that make you uncomfortable.

Be so good they cannot ignore you.


Categories: : Career & growth

Get The Applicable Bytes here:
Growth in programming, technical leadership & AI