Switching usually comes from treating the choice as permanent and from quitting at the boring middle of each technology. Pick with a short decision rule, commit for a fixed window of about twelve weeks with one finished project as the exit condition, and only review the choice at the end.
What people tell me
Every few weeks I decide on a new direction. I started with web development, then a video convinced me mobile was better, then everyone was talking about AI, so I started Python, then I read that cloud pays more. I have beginner knowledge of five things and nothing finished. When I sit down to continue one of them, I start wondering if I picked the wrong one. I want to commit, but I am scared of wasting months on the wrong choice.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- The choice feels huge because you are treating it as permanent. It is a twelve-week experiment, not a marriage.
- Most switching happens at the boring middle, exactly when the real learning starts.
- Use a simple decision rule, commit to a fixed window, and define finishing as one working project.
- Keep a parking list for the new shiny things so you do not have to act on them now.
- Skills transfer between paths far more than it feels from the outside.
Why you keep switching
In the messages I get about this, the pattern is almost always the same. Someone starts a technology and enjoys the first two weeks, because everything is new and progress is visible. Then they reach the middle, where the tutorials run out, their own project gets messy and progress feels slow. Right at that moment, a video or a post suggests a different path is better. Switching feels like progress, because the new thing is exciting again.
It is not a discipline problem as much as a structure problem. Without a clear finish line, the middle of every path feels like a sign you chose wrong.
The choice is smaller than it feels
You are not choosing your career for the next thirty years. You are choosing what to learn for the next three months. Almost every path shares a large core: programming fundamentals, Git, debugging, HTTP, databases, writing clean code, deploying something. A web developer who later moves into cloud or AI brings most of that with them.
When you shrink the decision to its real size, it becomes much easier to make.
A decision rule you can use today
Score each option you are considering from 1 to 5 on these four questions, then pick the highest total. Do not agonise over the scores.
| Question | Why it matters |
|---|---|
| Do I enjoy the kind of feedback this work gives? (visual, data, systems) | Enjoyment keeps you going through the middle |
| Are there entry-level jobs for it where I want to work? | Check real listings, not videos |
| Can I build something useful with it within three months? | Fast, real output keeps motivation up |
| Do I already have a head start? | Reusing what you know compounds |
If two options tie, pick the one with more entry-level listings. For most people starting out, that ends up being web or backend development, and that is a perfectly good default.
Commit with an exit condition, not a feeling
The key is to decide in advance when you are allowed to reconsider. I suggest:
- Twelve weeks on one path, written on a calendar.
- One finished project as the goal: deployed, working, with a short README. Not three half projects.
- A weekly check-in where you ask only whether you did the planned hours, never whether you picked the right path.
- A review at week twelve, with the project in front of you. Only then are you allowed to switch.
This removes the daily debate. The question is no longer "is this right?" but "did I do this week's work?"
Keep a parking list
The shiny things will keep coming. Every time you feel the pull toward a new technology, write it on a parking list with one sentence on why it interested you. Then close the tab. At your week twelve review, read the list. Most items will have lost their appeal. If one keeps appearing, that is real signal, and you can choose it deliberately next.
Recognise the middle when you hit it
The feelings that tell you to switch are usually the feelings of learning:
- Your project has bugs you do not understand.
- The tutorial does not cover what you need.
- You are slower than you expected.
- Someone online says your technology is dying.
When you notice these, say to yourself: this is the middle, and the middle is where skills are built. Then do the smallest next step, like fixing one bug or adding one feature.
What you do with the five half-starts
You have not wasted the time. Pick the one closest to the path you choose and reuse what you learned. If you did some Python and now choose backend development, Python is a fine backend language. If you did some web and now choose mobile, your JavaScript carries into React Native. Treat the past as a head start rather than a failure.
An example of the twelve weeks in practice
Here is what this looks like for someone who scores web development highest and commits to it:
- Weeks 1 to 3: JavaScript fundamentals, HTML and CSS basics, Git. Small exercises daily. By week three, a static page deployed online.
- Weeks 4 to 8: one project, say a habit tracker, built with a front-end framework and a small API. Each week ends with something working.
- Weeks 9 to 11: sign-in, a database, a few tests, a README with screenshots.
- Week 12: review. Did you enjoy the work? Is there a next project you want to build in the same stack? Read the parking list.
Notice what is missing: no second technology, no new course halfway through, no "quick look" at a different field.
A self-check for when the urge to switch arrives
When you feel the pull to change direction mid-way, answer these honestly before doing anything:
- Am I switching toward something, or away from a hard part of what I am doing?
- Have I finished anything in the current path yet?
- Would I still want this new thing if my current project were going well?
If the answers are "away", "no" and "probably not", you are in the middle, not on the wrong path. Close the tab and fix one small thing instead.
If you are still stuck
Read What to do when you are stuck learning to code and The defaults I would learn first as a software engineer. 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
- What to Do When You Are Stuck Learning to CodeThere has never been more good material for learning to program and the failure rate has not improved, which tells you the bottleneck is not access to explanation. It is that watching someone else solve a problem feels exactly like learning and is not. Sixteen heuristics for the first year, mostly about what to do at the point where you are stuck.
- The Defaults I Would Learn First as a Software EngineerEvery roadmap for learning software engineering is the same technology list in a different order, and it tells you nothing about what to do when you are sitting in front of an unclear requirement on a Wednesday afternoon. Fourteen situations you will keep meeting, paired with the move that is usually right, from prototyping a vague requirement to blaming the system rather than the person.
- 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.
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.