Choosing a path for the next six to twelve months is not a life sentence. Most doors in tech stay open far longer than students think, because the fundamentals transfer. Pick the option you can test fastest, commit for a fixed season, and judge it on evidence rather than on how exciting it looked from outside.
What people tell me
I like web development, but AI looks exciting, cloud seems well paid, and cybersecurity sounds interesting too. Every few weeks I watch a video about a different field and start a new course. I have lots of half-finished tutorials and nothing I can show. I am scared that if I pick one area, I will regret not choosing another, and I will have wasted my time.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- You are choosing a season, not a career. Commit for six months, then review on evidence.
- Most fields in software share the same base: programming, data, networks, debugging and working with people. That base never goes to waste.
- Score options on what you can test quickly and what you enjoy doing on an ordinary Tuesday, not on hype.
- Keep one small side interest on purpose, capped at a few hours a week, so curiosity has somewhere to go without taking over.
- Depth in one area makes it easier, not harder, to move into another later.
The fear behind the question
When someone tells me they have too many interests, the real worry is almost never about interests. It is about loss. Choosing web development feels like saying no to AI forever, and nobody wants to be the person who picked the wrong door in 2026.
So let me start with the part that usually calms people down: in software, very few doors close in your first few years. They close slowly, and mostly because people spread themselves so thin that they never get good enough at anything to be hired. The bigger risk is not picking the wrong field. It is picking none.
Why the doors stay open
Almost every path in tech sits on the same foundation:
- Writing clear code in at least one language.
- Understanding how data is stored, queried and moved.
- Knowing how the web and networks actually work.
- Debugging, reading other people's code, and using Git properly.
- Explaining your work and working in a team.
A backend developer who moves into cloud keeps all of that. A web developer who moves into AI engineering keeps all of it too, and is often better at shipping AI products than someone who only studied models. When I look at engineers who changed direction successfully, the common thread was depth in something first, not early breadth.
Choose a season, not a career
Replace the question "what should I do with my life?" with "what will I focus on for the next six months?" That is a decision you can actually make. At the end of the season you review, and you either continue or switch with far more information than you have today.
To pick the season, score your top three options honestly:
| Question | Option A | Option B | Option C |
|---|---|---|---|
| Can I build something real in it within four weeks? | |||
| Are there junior roles for it where I want to work? | |||
| Did I enjoy the boring parts when I tried them? | |||
| Does it build on what I already know? | |||
| Could I explain why I chose it in one sentence? |
Give each a score from one to three. The highest total wins the season. If two tie, pick the one you can test fastest.
The third row matters more than it looks. Everyone enjoys the exciting demo. The job is mostly the boring parts: reading logs, fixing edge cases, writing tests, configuring things that refuse to work. Choose the area whose boring parts you can tolerate.
Test before you commit
If you genuinely cannot decide, run a short experiment instead of another round of videos. Give each of two options one focused week and build the same small thing in each context. For example, a simple notes app as a web project, then the same notes with a search feature using an AI API. Notice which week you kept working past the time you planned. That signal is worth more than any ranking of salaries.
Two weeks of building beats two months of watching.
How to commit without feeling trapped
Once you have chosen, protect the decision:
- Write it down with an end date. "From October to March I am focusing on backend development with Node.js and PostgreSQL."
- Define what done looks like. Two deployed projects, one contribution to someone else's code, and enough confidence to explain your decisions.
- Give curiosity a small, fixed room. Keep one side interest at two or three hours a week. Read about AI on Sunday if you want. Do not start a new course in it.
- Delete the other half-finished courses from your plan. Not from existence, just from this season.
- Review at the end date, not before. Doubts in week three are normal. They are not data.
When switching is the right call
Sometimes you pick something and it really does not fit. Switching is fine when your reasons look like the left column, not the right:
| Good reasons to switch | Poor reasons to switch |
|---|---|
| You have built things and consistently dislike the daily work | A new video made another field look exciting |
| There are almost no roles for it where you can work | A friend got a job in a different area |
| You found a field that uses what you have already learned | You hit the first hard part and it stopped being fun |
If you switch, carry your projects and fundamentals with you. Nothing you built in the first season is wasted if you can explain what you learned from it.
What depth actually gives you
Students often think a generalist profile looks safer. In hiring, it usually looks unfocused. A CV that says "Python, React, Flutter, AWS, TensorFlow, Kali Linux" with small tutorial projects in each is weaker than one that shows two solid projects in one area and explains the decisions behind them.
Depth also changes how you learn. The second area is always faster than the first, because you already know how to learn a stack properly, how to debug, and how to read documentation. That is the real reason not to fear choosing: the first path teaches you how to walk any of the others.
If you are still stuck
Read How to Start Your Career as a Software Engineer and The Fundamentals Worth Learning as a Software Engineer for the base that transfers everywhere. If you want to see what real projects in each area look like, browse the FYP ideas library. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- How to Start Your Career as a Software EngineerA practical route into the first software engineering job: pick one language and stop shopping, build things too big for a tutorial, learn the five fundamentals you cannot skip, get your code in front of a human, and apply earlier than you feel ready. Includes a twelve month shape to work to and an honest read on what the current entry level market has changed.
- The Fundamentals Worth Learning as a Software EngineerFrameworks are the fastest moving and least valuable part of what you know. This is the layer underneath: how a computer runs your code, data structures as trade offs, complexity at conversational depth, storage, networks, concurrency, version control, testing as a design tool, and the two skills engineers skip that decide how far they get.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.