Stop Chasing Tech Stacks: What a Devsinc Seminar Made Me Rethink About Software Engineering

Not one of those things was useless.

And here lies the subtlety of the problem – at some point, I began to view technologies by their names as milestones.

Knowing MERN? Moving forward. Knowing Next.js? Moving forward again. Knowing PostgreSQL? Moving forward. LangGraph? Again moving forward. And each time when I felt familiar enough with a particular piece of technology, the internet suggested something else for me to learn.

This leads to a peculiar style of studying in which it takes months to feel technically more occupied without ever having asked myself whether I become a better engineer.

The seminar forced me to ask this question.

The Technology Really Does Change This Fast

The presenter's argument makes more sense when you look at what is actually happening in the industry.

GitHub's latest Octoverse data showed TypeScript moving to the top of GitHub's language rankings, while Python continued growing heavily alongside the AI boom. In AI-tagged repositories alone, GitHub counted more than 582,000 Python repositories in 2025, up about 50.7% year over year. GitHub Octoverse: AI and programming-language trends

It holds a different kind of meaning: the ranking of technologies below us in our professional lives will constantly change.

When I identify myself as “a Next.js developer,” what will happen if the industry moves on? When someone else identifies himself as “an AI framework developer,” what will happen two years down the road when that framework becomes obsolete?

Technologies definitely matter. Of course they do. Employers will hire those who know how to develop using the technology they have.

Can Someone Really Learn a New Stack in a Week?

That is when I partially disagree with the seminar message—at least, assuming its literal interpretation.

There is no way to conquer an entire ecosystem in one week.

You could probably create a basic Next.js app in one week. It doesn't imply that you comprehend rendering, caching, auth mechanisms, deployment process, performance problems, and the many weird edge cases which occur after several months of use.

It is true for Django, Laravel, Spring Boot, .NET and most other frameworks.

But I don't think “learn a stack in one week” was the essence of the message.

Imagine two developers dealing with a new backend framework.

The first developer only knows the exact framework they learned from a course. They know which folders to create, which commands to run and how their instructor structured an API.

Developer two has knowledge of HTTP, requests and responses, authentication, database relations, asynchronous processing, validation, error handling, caching, APIs, and the general structure of backend systems.

Both developers are new to the framework.

However, there is only one developer who is truly new from scratch.

The second developer may not know the syntax of the framework, but through documentation, they can figure out how it defines routes, uses middleware or connects to a database.

However, what is behind all of that is already known to them.

That was the seminar point I eventually agreed with: strong fundamentals reduce the cost of changing technologies.

The Awkward Question: What Actually Counts as a Fundamental?

Once I understood it that way, “learn a stack quickly” stopped sounding like a motivational exaggeration and started sounding like transfer of knowledge.

“Focus on fundamentals” is also one of those pieces of advice that sounds intelligent while saying almost nothing unless somebody explains it.

For a long time, I probably would have answered with data structures and algorithms.

They absolutely belong there, but software engineering is much larger than solving an array problem.

In the case of developing web applications, I need to know what happens when a browser requests something instead of considering fetch() as the point where network operations start and end. I need to understand the representation of data in the database instead of being aware of just calling an ORM. I need to know about the purpose of authentication, about the thing that authorization is trying to protect, about what a process is, about the problems associated with concurrency, about the communication between APIs and about how to debug a system in the absence of helpful messages.

Fundamentals also include learning how to split an ill-defined problem into smaller problems.

This Connected Directly With My “Confused Programmer” Problem

I recently wrote about something that had been bothering me for a while: the more technologies I learned, the less certain I sometimes became about where I was heading.

I called that article The Confused Programmer: Why Learning More Made Me Feel Further Behind.

I was confused mostly in terms of where to go. Full-stack engineering or backend engineering or AI engineering? Should I stick to Next.js as my main stack or switch to Python? Learn cloud? Agentic AI?

The seminar did not provide me with an answer to these questions.

It asked a different question.

I had been asking:

Which stack should I become?

Now I think that is a strange way to describe a software engineer.

I shouldn't be Next.js.

Next.js is a tool I currently use.

A better question for me is:

What kind of problems do I want to become capable of solving?

Once I ask that, the technologies still matter, but they move into their proper place.

They become tools chosen in service of the problem instead of identities I keep trying on.

AI Makes This More Important, Not Less

This becomes a very important issue since we learn software engineering in such a strange time period.

AI is capable of removing a lot of friction out of coding.

According to the 2026 Stack Overflow Developer Survey, coding assistants and coding agents have become the leading professional AI use case. Around 66% of respondents using AI reported using coding assistants or agents, and 73% of those users use them daily. Stack Overflow 2026 Developer Survey — AI usage

My SaaS Project Is Where This Became Real for Me

I've been experiencing the same lesson while building a multi-tenant SaaS application.

At first glance, it makes sense to consider the project from the perspective of technologies.

1. Next.js.
2. PostgreSQL.
3. Authentication library.
4. Deployment service.

However, those issues are not related to Next.js.

How do I divide each tenant’s data?

How do I handle cases where one person belongs to two organizations?

Do I scope all queries by tenants?

Where does the authorization happen?

What is the set of assumptions I make at the moment, which will be hazardous as the number of users increases?

All of these issues remain relevant, even if I use another technology in the future.

The syntax changes.

The APIs change.

The package names change.

The engineering challenge remains unchanged.

This seems to be the best example of the point the presenter wanted to convey.

A tutorial teaches me how to implement a route.

A roadmap tells me that I should learn PostgreSQL.

However, it is the project itself that reveals my misunderstanding.

This provides a much better learning process.

My Roadmap Hasn't Disappeared. It Has Changed Order.

I still use Next.js.

I still have the goal to get better at PostgreSQL.

I am still interested in Payload CMS, Python, LLMs, AI agents and automation.

The seminar did not make them less relevant.

It repositioned them for me.

My previous tech stack roadmap would be something like:

Technology → tutorial → project → next technology

And I hope for the new one to be more like:

Problem → understanding → choosing technologies → building → failing → researching → improving

Which implies that I don't immediately start tutorials for a new framework when it appears.

I can first ask myself several questions.

1. What problem does it solve?
2. What does it abstract away?
3. How does it do what it does?

Which of my existing knowledge works there?

Would it actually improve my current system?

And only if I really need it, I will go on and learn.

The odd thing about this methodology is that it might actually lead to faster acquisition of new stacks, since you don't need to memorize an entirely new world anymore, but only map unfamiliar syntax to your existing knowledge.

Maybe This Is What “Software Engineer” Is Supposed to Mean

As a beginner in my learning journey, I used to assume progress was about having more knowledge.

Having more languages in my CV.

More technologies listed under skills.

More tools I could identify.

I don’t believe that is entirely incorrect now. But it is, however, incomplete.

There is another kind of progress which is much harder to prove on LinkedIn.

You learn to analyze an ambiguous situation and figure out the true problem behind it.

You don’t freak out when the tutorial for the exact situation isn’t there.

You can actually read some documentation and relate it to the situations you already know.

You know enough of what your technology hides from you so that you have somewhere to look at when abstraction fails.

You can question an AI-generated solution because you understand the trade-off rather than the other AI tells you to.

Perhaps the most important thing is that when a new technology comes in, it no longer makes you feel like all the years of learning were wasted.

That is what stayed with me after the Devsinc seminar.

I will probably continue learning too many technologies. Curiosity is one of the reasons I got into software engineering in the first place, and I don't want to lose that.

What I do want to stop doing is confusing the tool I'm learning this month with the engineer I'm trying to become over the next decade.

Frameworks will evolve.

The stack I'll use in five years time might bear little resemblance to the one that I currently describe on my website.

However, if I'm able to analyze a problem, decompose it into its constituent parts, reason about the underlying system, use appropriate tools, identify an incorrect solution and debug when necessary

then perhaps I don't even have to guess the optimal stack at all.

I just have to become more difficult to replace.