Don’t Just Learn What’s Hot. Learn What’s Next.

This week, I had a very interesting conversation about my career.

For the first time, I wasn’t talking about my career as a job applicant. I was talking about it as a senior software engineer who wanted to share her experience, knowledge, and story.

And I enjoyed it.

This morning, I was thinking about that conversation when a question crossed my mind:

How did I actually get here? And what was one of the most important things on my journey to becoming a senior software engineer?

Surprisingly, I think part of the answer is this:

Don’t just learn what is popular today. Pay attention to what might become important tomorrow.

How did it begin for me?

In high school, I was excellent at biology. I loved genetics and represented my school in several biology and chemistry competitions.

I genuinely loved it.

But I had another hobby: smartphones.

My husband once told me that, for teenagers, smartphones are often a status symbol. I think he has a point.

But for me, they were something more.

I loved taking old phones apart, playing with new applications, and discovering new features and gestures. As a teenager, I dreamed about owning an iPhone — not because of the status, but because of the software.

I had a BlackBerry Q5 and later a Q10, and I absolutely loved the brand.

At university, I received a scholarship and used the money to buy my first iPod and, later, an iPhone SE.

I loved the software experience. It felt exceptional.

And yet, I continued with biology.

Becoming a developer wasn’t even part of the plan.

That changed near the end of university, when I started programming a lot because of my diploma thesis.

And after that?

Yeah. Somehow, I became a junior software developer.

My First Burnout in IT

I started working as a backend software developer.

And after my first job, I was burned out.

Not “I need a relaxing weekend” burned out.

Properly burned out.

I knew I didn’t want my next job to be another backend position. What I really wanted was to become a mobile developer.

At the time, Flutter and React Native were everywhere.

But I wanted to work with Kotlin.

So I started learning it.

Sometimes You Need to Step Up

Whenever I looked at backend job descriptions or went to interviews, I had serious FOMO.

There was always something else I was supposed to know.

Another framework. Another technology. Another concept. Another thing my senior Java colleagues seemed to understand better than I did.

I felt too inexperienced for backend development and wondered whether I would ever be as good at Java as the senior developers around me.

My knowledge felt like a sandcastle.

Every new wave was a problem.

And at some point, I realized that maybe the solution wasn’t to keep desperately adding more sand.

Maybe I needed to build somewhere else.

Why Android? Why Kotlin?

When I started looking seriously at mobile development, there were plenty of Flutter and React Native jobs.

Kotlin positions?

Not so many.

But I started looking at the signals rather than just the number of job ads available at that exact moment.

Android had Google’s backing, and Google had made Kotlin a first-class language for Android development.

That was enough to make me curious.

Instead of learning whatever happened to appear most often in job descriptions, I decided to start with a clean slate and focus on the modern Android ecosystem:

Kotlin as my primary programming language
Jetpack Compose for modern Android UI development
Material Design libraries
MVVM and modern Android architecture patterns
Room for local data persistence
New Android tools and libraries as they appeared

I built practice projects.

I experimented.

And eventually, I deliberately chose a company that gave me the freedom to work with Kotlin on real Android applications.

That decision changed my career.

Later, when I looked for another Android developer position, something interesting had happened.

Finding Kotlin opportunities wasn’t a problem anymore.

There were plenty of them.

Learn to Read the Signals

This is probably one of the biggest lessons I’ve learned during my software engineering career.

Learning what companies need right now is important.

But stopping there can be dangerous.

Technology moves too quickly.

You don’t need to predict the future. You don’t need a crystal ball next to your mechanical keyboard.

But you should learn to notice signals.

Ask yourself:

Where is the ecosystem moving?
What are the major companies behind the technology investing in?
Which tools are becoming first-class citizens of their platforms?
What are developers experimenting with today that companies may need tomorrow?
Which skills complement what I already know?

There is obviously a risk.

You might learn something that never becomes mainstream.

But blindly following today’s job market has a risk too: by the time you’ve mastered what is hot today, the market may already be moving toward something else.