100 projects illusion

(PDF Download at the bottom)

You can have 100 projects and still not be senior.

Because repetition is not the same as growth.

That sounds obvious when you read it.

It was not obvious when I lived it.

After five years of programming, I looked strong, on paper: around 100 projects, a team lead title, and forum administrator credibility from the old PHP days. Those things helped me get my foot in the door in Norway.

But they did not mean I was senior.

They meant I had done a lot of work.

That is different.

Here’s the uncomfortable part: a long project list can make you confident in the exact habits you should be questioning.

The first job created the perfect illusion

In my first company, we built about a website a week for around four years.

That is a lot of output.

For a CV, it looked beautiful. If someone asked about experience, I could say “100 projects” and feel like the express train had arrived at the station.

And to be fair, it was not fake experience.

I learned speed. I learned client work. I learned how to deliver. I learned how to talk to project managers and customers. I also got my first chance to lead people, which went badly at first because my ego was bigger than my skill.

Very educational. Not very pleasant for everyone around me.

But there was a catch.

Around 60 of those projects were probably very similar.

Same kind of websites. Same kind of problems. Same CMS. Same framework. Same route.

And when you drive the same route every day, you get good at that route.

You know the corners. You know the traffic. You know where the road gets weird.

But that does not mean you can drive anywhere.

That was my mistake.

I counted projects, but I did not count variety, difficulty, or fundamentals.

Project count is evidence, not proof

A project list can prove that you showed up.

It can prove that people trusted you with work.

It can prove that you can finish things.

But it does not automatically prove that your skills are deep.

If the projects are similar, they may only prove that you got faster at the same patterns. And if some of those patterns are bad, you are not just practicing skill.

You are practicing debt.

This is where many developers get trapped around five to ten years in.

You are no longer a beginner. You can deliver. People trust you. Maybe you even have a senior or lead title.

But your confidence is built inside a narrow environment.

Then something changes.

A different product. A different company. A deeper interview. A system that has to live longer than your usual project cycle.

That is when the illusion starts making noise.

Norway exposed the gap

When I moved to Norway, I thought my experience would carry me.

After all: I had around 100 projects.

I had been a team lead.

I had been active in forums.

I had already survived real client work.

Then I joined a small company in Bergen, and the work changed.

This was not another typical website.

It was an app for one client, and it had to be developed and maintained for many years. Requirements changed. The product evolved. The code had to survive.

My code did not like that.

Not one bit.

Suddenly the old tricks were not enough. The thing that worked fine when projects were small and short-lived started breaking when the product had to keep changing.

I knew one CMS and one framework. But I had skipped too many basics.

Object-oriented programming was weak. Refactoring was scary because changing one thing broke three other things. The code became tightly coupled spaghetti, like WordPress if WordPress had a bad week.

And then the painful sentence arrived:

I was not senior. I was a junior developer carrying five years of bad habits.

That sentence hurts writing, even after 20 years of experience.

It also helped.

Because once you name the problem correctly, you can finally stop solving the wrong one.

Long-lived products reveal the truth

Short projects can hide weak fundamentals.

A long-lived product usually cannot.

When you build a website, ship it, and move on, you may never fully feel the cost of your decisions. The next project gives you a clean start, and the old mess becomes somebody else’s archaeological expedition.

But a product that lives for years keeps asking questions:

Can this code change without breaking?

Can another developer understand it?

Are the boundaries clear?

Are the objects doing too much?

Is the system flexible, or did we just glue features together until everyone was afraid to touch it?

That kind of product does not care about your CV.

It tests your fundamentals every week.

And if your fundamentals are weak, it will show.

Maybe not on day one.

But eventually.

And this is still relevant in AI age, when we have less control of ourcode.

You need to know your sh*t!

I blamed the wrong things first

At first, I did what many developers do.

I blamed the client.

“They keep changing requirements.”

I blamed management.

“They do not know what they want.”

I blamed the project.

“Next time, with a fresh codebase, I will do it properly.”

All of that felt reasonable in the moment.

But the deeper truth was not outside me.

The deeper truth was that I did not know how to build software that handled change.

Losing my life savings before moving to Norway was a tragedy of luck.

Being a fake expert was a tragedy of my own making.

That is a hard distinction, but it matters.

Because if the problem is only the client, you wait for a better client.

If the problem is only management, you wait for better management.

If the problem is your fundamentals, you can start fixing it today.

The market made it even clearer

When the company situation was not great, I started looking for a new job.

I thought that would solve the problem.

Very optimistic. Very wrong.

At that point, I had 101 projects, a Norwegian work permit, and I was already living in Norway.

It still took me about one and a half years and probably ten interviews before I made progress.

That was not a fun period of my life.

One problem was that PHP was not that popular in Norway.

But the bigger problem was depth.

I could say “100 projects” in an interview, and that sounded good for about five seconds. Then people started asking deeper questions.

Why did you structure it this way?

How would you refactor this?

What happens when requirements change?

How do you reduce coupling?

What tradeoffs did you make?

And there was not much depth to dig into.

That is when I learned another painful rule:

A project list can open the door, but fundamentals decide whether you can walk through it.

Interviews are not perfect. Some are bad. Some test the wrong things. Some companies do not know what they want either.

But a deeper interview can still expose the difference between project history and transferable knowledge.

And mine was exposed.

The real problem was learning debt

The recovery did not come from adding 20 more similar projects.

That would have only made the illusion bigger.

The recovery came from learning what I had skipped.

Later, I sat down and learned JavaScript, TypeScript, Angular, and better programming practices. It was slow, painful, frustrating, and honestly quite embarrassing.

It felt like paying off ten years of learning debt in six months.

But it changed everything.

Not because those specific technologies magically made me senior.

They did not.

The important part was that I finally started learning deliberately instead of only surviving the next task.

There is a big difference.

Survival learning is when you learn just enough to finish the ticket.

Deliberate learning is when you ask, “What am I missing that keeps creating the same problems?”

That question is where real growth starts.

Audit your own 100 projects

If you are five to ten years into coding, this is the part I would not skip.

Look at your own project list.

Not to feel bad.

To see clearly.

Ask yourself:

• Were these projects actually different, or mostly the same shape?
• Did the work force me to learn new fundamentals, or only new syntax?
• Can I explain why the system was structured the way it was?
• Can I refactor safely, or do I mostly hope nothing breaks?
• Do I understand object-oriented programming beyond class names and inheritance diagrams?
• Can I handle changing requirements without blaming everyone around me?
• If an interviewer digs below the CV, do I have depth?

If the answer hurts a little, good.

That is not failure.

That is the map.

The dangerous developer is not the one who has gaps. We all have gaps.

The dangerous developer is the one who has gaps, but protects the ego instead of fixing the skill.

Repetition can be useful, but only if you inspect it

Repetition is not bad.

You need repetition to get good.

But repetition without inspection can turn into professional sleepwalking.

You do the work. You ship. You get praised. You become faster.

Then one day, a changing product or a serious interview asks for depth, and you realize you were mostly repeating the same route.

That moment is painful.

But it is also useful.

Because once you see the difference between “I have experience” and “I have repeated habits,” you can choose differently.

Choose one missing fundamental.

Refactoring.

Object-oriented programming.

Coupling.

Architecture.

Testing.

Debugging.

Pick one, and learn it properly.

Not because a course certificate will save you.

Because the next level of your career will require skills your current route may never teach you.

Watching is understanding, doing is learning.

Download the PDF to inspect your 100 projects, find the repeated route, and start paying down the learning debt before the market does it for you.

Categories: : Career & growth