The Confused Programmer: Why Learning More Made Me Feel Further Behind

Then AI appeared to be inevitable. Having previously been acquainted with Python due to university education, delving into AI felt natural rather than being an entirely new sphere. I was getting to know more about large language models, RAG, APIs, Lang-Graph, agents and automation.

And it was enjoyable.

It was supposed to make things clearer.

But instead, it opened another possibility for my future self.

Did I want to be a full stack engineer able to develop entire software products?

Did I move towards AI engineering?

Or maybe focus on back-end systems?

Did I have to combine software engineering with AI automation?

Or maybe just jump at whatever interested me each week?

The internet was more than willing to answer those questions for me. The problem was that everybody had a different answer.

The Problem With Roadmaps Is That Most of Them Are Reasonable

Go to a site like roadmap.sh and you can find roadmaps for frontend development, backend development, full-stack engineering, DevOps, cybersecurity, AI engineering, machine learning, software architecture, MLOps and dozens of other directions.

That is useful.

It can also be somewhat scary because at the same time, you do not know what kind of engineer you want to become yet.

Open the full-stack roadmap and everything seems to be significant. JavaScript, frontend technologies, APIs, databases, authentication, Docker, cloud deployment and system design all make sense. Then, open an AI engineer roadmap, and that also makes sense. Now Python, machine learning basics, LLMs, vector databases, RAG, agents, evaluation and deployment seem to be things you have to know. Then, you hear from someone that good AI engineers should have good backend engineering skills since AI products are still software systems with models.

That sounds right.

Some other developer tells you to not pursue AI until your computer science fundamentals are solid.

Also reasonable.

Someone else says you should specialize early because generalists struggle to stand out.

Another says the most valuable developers are increasingly people who can work across multiple layers of a product.

You can spend an incredible amount of time consuming advice from people who are all making reasonable arguments.

I eventually came to understand that it wasn’t about not knowing anything. I had too much to know.

And rather than asking what I wanted to build, I asked what technology I should learn. They sound similar enough,

but I think they produce very different programmers.

Somehow I Was Improving and Still Feeling Behind

This is what made it hard to identify the problem. If I had been sitting around for a whole year and doing nothing, it would make sense to feel like I had fallen behind.

But I hadn't.

I could build full-stack web applications. I could handle databases and APIs. I could integrate with CMSs, authentication services, and deal with deployment and production-related problems. I was getting better at building things in Next.js and PostgreSQL while also tinkering with AI systems and agents. Coding which once would look like gibberish to me became comprehensible.

The more boxes I could check off, the harder it was to answer a fairly basic question:

Who am I as a programmer?

“Software engineer” seemed too vague a term.

• “Full-stack developer” seemed too accurate, as it didn't reflect my current interests.
• “Next.js developer” was too specific to one technology stack.
• “AI engineer” seemed to be an overstatement.
• “Freelancer” was more about how I had worked rather than what I was trying to achieve.

Finally, “a bit of everything” never sounded like a comforting thing to say about myself.

University Can Make the Confusion Worse

The funny thing is, there’s a bizarre juxtaposition between university education and the tech industry. University promotes breadth – that’s quite obvious. It’s important for a software engineer to be aware of the existence of operating systems underneath their Node process, networks underneath their HTTP request, and databases being more than just a package installation. However, while the university actively introduces you to a variety of disciplines, the industry insists that you choose only one of them.

Thus, in the same week, you’re living different technical lives.

One day, I can be working on parallel computing in the university, while another day – considering the architecture of the database for my Next.js application. Or playing around with LangGraph and thinking of how an AI agent must maintain state.

After that, I make the mistake of opening LinkedIn.

Someone my age has just become a machine-learning engineer.

Someone else has launched a SaaS product.

Another student has landed a remote development role.

Then somebody writes a dramatic post explaining why the technology I've spent the last year learning is supposedly dead.

Five minutes earlier I was happy because I had finally solved something in my own project.

Now I'm reconsidering my career.

Nothing about my ability changed during those five minutes.

Only my reference point changed.

That has probably caused me more unnecessary career confusion than any programming language ever has.

AI Has Made This Problem More Complicated

There is one other reason why all this is important. Now, I can go into a technology about which I know little, tell what I am trying to build to ChatGPT, Claude, Gemini, or another coding assistant, and accomplish surprising things. This is an absolutely amazing advantage compared to the software development I would have learned even a few years ago.

I am using these technologies myself. I don't want to pretend like developers shouldn't be using them. But I have realized that AI makes it much easier to hide your deficiencies in the matter.

There is a significant difference between now:

I know how to develop this.

and

I know how to make this developed.

Both are important skills. But they are not the same.

You can see that difference in the moment when the code written by the assistant is almost right, but not quite. It uses the wrong library. The authentication flow works differently in the real world. The two packages do not work well together. The database schema does not support some functionality anymore.

It's at that moment when the prompting is not as useful as the knowledge.

Building a SaaS Changed How I Look at Learning

One of those things that have benefitted me recently hasn't been another course either.

Instead, it was developing a SaaS application for multiple tenants.

Having to build a bigger project right away changes your questions.

The app doesn't need to know what kind of technology is hot these days on LinkedIn. It gives you problems. How can we isolate data by tenants? Should they share tables or be more isolated? How can authentication and organizations co-exist?

Where should the business logic be implemented?

What if there will be hundreds of tenants instead of just five in the future?

Those questions naturally create a learning roadmap.

I needed to learn more about PostgreSQL because I had a real design problem with it. I needed to think about software architecture because choices that I made today would be difficult for me tomorrow. I needed to think harder about authentication because "login works" was very different from designing access control between different organizations. I've written about some of these choices in a separate blog post about my multi-tenant SaaS architecture, since this is one of the projects that my software engineering education will start bearing fruit.

And that brought a change in something crucial for me.

In the past, the process usually went like this:

Learn → Learn something else → Learn another thing → Eventually Build

And now, I'm trying to turn it around:

Build → Run into a problem → Learn to solve this problem → Solve it → Continue building

The latter approach gives sense to the learning.

I'm Not Choosing My Forever Stack Anymore

I believe I had part of my dilemma because I was approaching every technical decision as a career decision.

If I pick Next.js, am I a JavaScript developer forever?

If I dive deep into AI, am I done with traditional software engineering?

If I invest months in becoming a better backend developer, am I wasting time that I could spend learning machine learning?

That kind of pressure does not have to exist. The career in technology is simply too long, and the technology itself is evolving too fast for me to have a clear idea of what I will be working on ten years from now.

Also, I cannot have a notion of what technologies will be there in ten years from now. Rather than selecting my forever stack, I am choosing the type of engineer I want to be in the coming few years. Right now, I am looking to become an expert in creating entire software products. I want to be knowledgeable in front end technologies when needed, design backend properly, work with databases, make good architectural decisions and deploy software that can withstand life outside localhost.

Maybe Feeling Behind Wasn't the Real Problem

Back when I knew next to nothing about programming, software engineering seemed suspiciously small.

HTML. CSS. JavaScript. React.

Maybe Node.

Done.

Every year since then has only made this picture bigger.

Now there is not just a website but also databases, networking, operating systems, distributed systems, software architecture, security, infrastructure, machine learning and AI systems behind that website.

This picture did not grow because I failed.

Finally, I got to see it.

And apparently, I am not the only one who experienced it. As the Stack Overflow survey revealed, developers learned hundreds of technologies, and languages like Python were growing further because they started to span across multiple domains: backend development, data science, and AI.

Perhaps that is the reason why becoming better makes you temporarily feel worse.

At the beginning of your journey, you have no idea about all that stuff.

Eventually, you have some knowledge.

The problem is that after seeing this enormous map of technology, I was expecting to explore everything on it.

I shouldn't.

Neither should any other student who tries to become a programmer.

For now, I plan on keeping my stack long enough to actually get good at it. I’m creating projects that are bigger than anything I’ve created before. Then I’ll learn whatever knowledge is missing after that.

There will most likely still be times when some other person’s LinkedIn post makes me second-guess myself for ten whole minutes. I’m fixing that problem as well. But unlike in recent years, there isn’t some perfect map right in front of me.

And for some reason, I feel less confused without one.