The 2026 Learning Roadmap From Zero to Engineer: What to Learn, in What Order, and How Much

This article is a detailed roadmap for complete beginners — working adults or students who are "about to aim for becoming an engineer," or who have just started studying and are stuck at the stage of "I don't know what to do next." The goal is that, by the time you finish reading, you have in hand a full map of "what to learn, in what order, and over roughly how long."

First, let me make this article's position clear. passed.jp is a site about growth through learning and getting better, and about the connections between people. So what this article covers carefully is only the stretch up to "building a foundation and reaching a state where you can keep learning on your own." It does not step into the practical side of getting a job — how to find openings, salary benchmarks, the reality of school guarantee programs. The goal this article wants to deliver you to is not the doorway to a job search, but a version of yourself who can keep learning.

There is one more caveat I want to place up front. Every number in this article — "rough study-hour estimates," "the share of people who give up," and so on — is an estimate. How long learning takes varies enormously from person to person, and published statistics differ in method and target, so there is no single "correct number." In the body, I avoid asserting specific figures as "fact" and present things as qualitatively as possible. Read on with the premise that, when you use a number to make a decision, you should check its source and its as_of (the point in time the information reflects). I don't use invented numbers or conveniently rounded statistics.

And the goal this roadmap defines is not "memorizing a specific language." Languages and frameworks come and go. What you're aiming for is a state where you can look things up yourself, move your hands, and keep going — in other words, becoming able to "self-drive."

Here's how to read on. First grasp the big picture (six steps), then look at the contents of each step in order, check your defenses against the "give-up points" where people tend to break, gather material for judging "self-study vs. school" by aptitude, and finish with "the craft of keeping at it and growing." You're welcome to skim from whichever section interests you, but if this is your first time, reading top to bottom will make it click why the order is what it is.

The big picture: six steps from zero to engineer, and rough timelines

Learning your way from zero to engineer becomes less bewildering if you split it into six big steps.

Basics / foundation — how computers and the Web work, file operations, environment setup
Choosing a language — pick your first single language by working backward from "what do you want to build"
Framework — get one representative framework for your chosen language running
Git / dev practice — version control, databases, APIs, deployment — "the foundation of real work"
Portfolio — turn your learning into "proof you can think and build"
Continuation — grow through systems for keeping going, and through connections with people

There's a reason for the order. Skip the foundation (step 1) and jump straight into a language or framework, and you'll keep freezing up because you can't tell "why this error appears" or "what this setting is doing." More haste, less speed: holding a map first tends to get you there faster in the end.

On total study-hour estimates. People often quote numbers like "◯◯ hours from beginner to an engineering job," but the premises (target language, the level you're aiming for, learning efficiency) differ completely by source, and the range is enormous. Some take their first step after short preparation; others spend a long time carefully. What matters here is not swallowing any specific number whole. If you want a concrete time estimate, check multiple primary sources (various surveys, figures published by schools) together with their as_of (reference point). Data tied to job openings and salaries is not something this article covers.

What actually helps as a personal matter is the mindset of "working backward from the hours you can secure per day." For the same total, the number of months to arrival changes a lot as the hours you can secure per day change. The table below is an example meant to show a "sense of pacing," not the amount of study itself.

Study hours secured per day	Felt sense of how long it takes
About 30 min on weekdays + 2 hrs on days off	Easy to sustain long without wrecking your life, but arrival takes a fair number of months
2 hrs on weekdays + plenty on days off	A standard pace. Tends to become a settled plan of several months and up
Nearly full-time (6+ hrs a day)	Progresses in a short intense burst, but burnout and life-breakdown risk must be managed

This table too is an "estimate" and guarantees no numbers. What I want to stress is that you don't have to drive yourself to match a "shortest ◯ months" hype. More than arrival speed, a design that lets you keep going without breaking midway decides success or failure in the end.

STEP1 Basics: the foundation of how computers and the Web work

What you want to acquire in the first step is not memorization but "holding a whole-picture map." This becomes the foundation for every later step.

There are four concrete things worth touching.

Get a feel for "how a screen gets built" with HTML/CSS. How text and images are placed, how color and layout get decided. Actually make a simple one-page site with your own hands, and you'll feel in your body that "a web page isn't magic — it's built from a stack of instructions."
Know the broad outline of how the Web works. A browser (client) asks some server, "please give me this page" (an HTTP request), and the server returns it. Just holding an image of this round trip makes the terms that come up in later study connect and become visible.
Basic operations for files, directories, and the terminal. Folder hierarchy, the sense of specifying where a file is, typing simple commands into the black screen (terminal). Leave a mental block here, and it will hold you back for a long time.
Setting up a development environment. Install an editor (the software you write code in) and useful extensions. This is the step of tidying your own "workspace."

A common pitfall is getting stuck on this first environment setup and being unable to move on. OS differences, version differences, error messages that make no sense — plenty of people melt several days here and break, motivation and all.

As a countermeasure, it helps to know options that reduce environment differences as much as possible. For example, cloud-type dev environments that finish entirely in the browser, or container technology that reproduces a whole environment inside a box, make you less likely to get pushed around by "mysterious errors that only happen on my machine." There's no single right answer; what works most here is simply knowing "if I get stuck, there's an escape route: try a different environment."

The time this step takes varies by person, but the trick is to proceed with the temperature of "move on once you have the map," not "move on only after perfect understanding." The basics deepen little by little as you come back to them again and again while advancing the later steps.

STEP2 Choosing a language: a language map working backward from purpose

The easiest trap here is getting hooked on the question "which language is strongest." To state the conclusion, there is no "strongest language." A language is a tool, and a tool is chosen by "what you want to build."

As a map working backward from use, you can roughly organize it like this (arranged by suited domain, not superiority).

Web frontend (around the screen) … JavaScript / TypeScript. Hard to avoid if you want to build things that run in a browser.
Web backend (server side) … Ruby, PHP, Python, Java, Go, and so on. Each has its strong domains and a thickness of learning community, and no single one is absolutely superior.
Mobile apps … If you want to make smartphone apps, the languages and environments used in that domain.
Data / AI / machine learning … A domain where Python is often used.

It's healthy to view each language fairly on axes like "suited domain," "the thickness of the learning community and documentation (whether help is easy to find when you get stuck)," and "job trends." That said, data directly tied to the number of openings or salary is not something this article steps into — this shifts with the times, so it's safer to consult primary sources rather than assert.

What a beginner should keep in mind first is the policy of "one to a practically usable level" over "shallow and wide." Touch several languages thinly at once and each stays half-baked, and a sense of achievement is hard to get. Narrowing to one first and stacking the success experience of "I could build something that runs" in that language tends to grow you faster in the end.

You may worry, "if I narrow to one and later can't adapt?" Rest assured: the foundation of programming (the ideas of variables, conditionals, loops, functions, data structures) is common across languages. Understand one deeply, and moving to a second or third language isn't as hard as the first. That's exactly why it's meaningful to choose your first one by "it's close to what I want to build," not "it's kind of popular." Keep your distance from information that pushes a specific language as "just do this and you win."

STEP3 Framework: what to stack after the language

Once you've touched the basic grammar of a language, the framework comes next.

A framework, roughly put, is "a scaffolded structure for building the usual features." A web app has "common mechanisms every app needs" — login, saving and retrieving data, displaying pages. Writing these from scratch every time is reinventing the wheel — it takes time and multiplies mistakes. A framework arranges those common parts in advance, so it's used as standard in real work too.

Here too, let me lay out the representative ones fairly (no single one is "the answer").

Frontend … React, Vue, and so on
Backend … Rails, Laravel, Django, Spring, Express, and so on

There are two important policies here.

Touch just one major framework for your chosen language, first. If you chose Ruby for the backend, then Rails; PHP, then Laravel — pick one representative framework matching your one language. Rather than endlessly comparing "which is best" until your hands freeze, choosing one and running it teaches you faster.
Don't over-learn. Frameworks run deep and their features are vast. Don't try to understand every feature from the start; prioritize "building something small but working, all the way to the end."

It also helps to sort out the relationship among library, framework, and ecosystem here, so you don't get confused. A library is "a part that helps with a specific feature," a framework is "the skeleton of the whole app," and an ecosystem is "the collection of tools and information gathered around it" — that's the image. You don't have to distinguish them all perfectly at this stage. As you run a small app on one framework, the outlines naturally come into view.

The time it takes varies a lot by language, framework, and secured hours, so treat it only as an "estimate" here too. The goal is not "keeping to a schedule" but reaching the state of "with one framework, I could build something that runs by my own hand."

STEP4 Git / dev practice: foundational skills that are essential on the job

Between "can write code" and "can do the work" lies a surprisingly large gap. This step fills it. And this is the part that tends to get pushed to the back in self-study and slowly takes effect after you're hired.

Here are the skills that become foundations on the job.

Version control (Git / GitHub) … a mechanism that records the change history of code so you can always roll back. Basic operations like commits (records of changes), branches (splitting off work), and pull requests (the flow of getting a change reviewed) are the common language of team development.
Working the terminal … taking the black-screen operations touched in STEP1 up to a level you use in real work.
Basics of databases and SQL … where and how an app's data is stored and retrieved. SQL is the language for querying that data.
Understanding APIs / HTTP … how apps, or apps and servers, exchange information. This is the step of re-understanding STEP1's Web mechanism more concretely.
Simple deployment (publishing) … taking something that runs only inside your own machine and publishing it online so others can touch it.

What I'd recommend here is running the small, work-like flow of "build → version-control → publish" all the way through, even just once. A small app is fine. Whether you have the experience of running this whole sequence by your own hand changes the quality of your learning greatly.

The conventions of team development — for example, the culture of not putting a change straight into production but having it reviewed first, or the way of writing out what needs doing as issues and managing them — are also enough to just "know such things exist" at this stage. After you're hired, you'll come to understand their meaning in your body. In our editorial view, beyond the power to write code, people who hold this "foundation of dev practice" tend to show a difference in how they get up to speed after entering the field.

STEP5 Portfolio: turning learning into "visible results"

A portfolio is not proof of study volume, "I studied this much." Its purpose is to show "I can think, and I can build."

For what to make, rather than a "clone" that copies a famous existing app as-is, I recommend a small app that solves your own troubles or a nearby problem. "The daily ◯◯ was a pain, so I built a tool to make it easier" — something with that kind of motive conveys your thinking power even at small scale.

The point of a well-received structure is, more than the number of features or flashy looks, whether you can put into words "why you built it, where you got creative, where you got stuck, and how you solved it." Writing things like the following in the README (the file that explains it) makes the value of what you made come across far more strongly.

What problem you wanted to solve by building it (the background)
What you got creative about
Where you got stuck along the way, and how you got over it

For how to publish, the basics are: put the code on GitHub, deploy it in an actually-running state, and make it touchable by following a link.

On numbers, it's "one deep" over "make many." Rather than lining up several shallow ones, building one properly — including the stuck parts — makes what comes across bigger.

Note that the practical discussion of how to present a portfolio in a job or career-change setting, and on what axes it's evaluated, is not something this article covers. What I want to stress here is only that "the process of building itself becomes the greatest learning." Making a portfolio is the work of mobilizing all the things you learned in fragments across STEP1–4 within a single flow. In the process of building it to completion, the basics settle in as "knowledge you can actually use."

Seven common give-up points and how to get past them

In learning from zero, people tend to break in similar places. Just knowing in advance that "getting stuck here is common" makes it easier to get past. You're not the only one who stumbles. People who stop their feet at the same spot are by no means rare.

Can't get past environment setup. → Don't shoulder it alone; use the "escape routes that reduce environment differences," like cloud-type environments and containers. This is a domain solved by "choice of tools" rather than "grit."
Error messages are scary, unreadable. → An error isn't "being scolded"; it's "a hint telling you where the problem is." Search the wording of the message (especially a line of English) as-is, and try reproducing the problem cut down to its minimal form. This habit of "look it up and isolate" is itself a core skill of an engineer.
The loneliness of self-study, no one to ask. → Belong to even one of the communities or study groups mentioned later. Just "having a place to ask" makes the anxiety of being stuck feel completely different.
Progress is invisible, and you get anxious. → Leave a study log, even one line. When "I got this far today" piles up visibly, anxiety turns into "a sense of traction."
Perfectionism stops you from moving on. → Make "works is OK, improve it later" your motto. Rather than freezing up trying to write beautiful code from the start, running it first and fixing it later makes learning move faster too.
Can't secure study time. → Drop it into "habit" instead of relying on "motivation." Get through with "design" — fixing the time slot, deciding on just 15 minutes in the morning. Systems last longer than strength of will.
You lose confidence comparing yourself to others. → Make your comparison "your past self." Others' progress visible on social media is a cross-section of the moment it went well. At your own pace, one step past yesterday, is enough.

Note that there's plenty of information out there quoting shares like "◯ percent of beginners give up," but when you cite that kind of number, always check its source and as_of, and treat it as an "estimate." The survey targets and definitions vary, and it's a domain where numbers tend to walk off on their own. I don't use invented percentages here. What matters is not an exact percentage but the point that "you're not the only one who breaks."

The very structure of why self-study breaks, and concrete ways to rebuild it with systems, are gathered in When Self-Taught Programming Won't Stick: Rebuild With Systems, Not Willpower.

Self-study vs. school: not which is above, but "choose by aptitude" — a neutral call

To the question "self-study or school, which is correct," I answer neutrally. Neither is above the other. You choose by your own aptitude.

Let me lay out the axes for the judgment symmetrically.

Cost … Self-study is easy to keep cheap. A school costs, and in exchange you buy environment and support.
Ease of securing study time … Self-study can be arranged at your own pace, but you have to discipline yourself. A school gives you a learning rhythm from the outside via its curriculum.
Personality / learning style … Are you a "self-driven type" who can grind alone, or a "paced type" who lasts better with someone running alongside?
Whether there's an environment to ask questions … In self-study you have to find someone to ask yourself. A school often has people ready to answer.
Recovery power when you stumble … Can you come back alone when stuck, or do you want a mechanism where someone pulls you up?
Whether you want "knowledge" or "support" … Is learning itself the goal, or do you want an environment that runs alongside you too?

Self-study's merits are that cost stays low and you can dig deep at your own pace, wherever your interest leads. Its demerits are that it's easy to become isolated, hard to notice when you've gone the wrong way, and you shoulder all of motivation management yourself.

A school's merits are a systematic curriculum, an environment to ask questions, peers with the same goal, and externalizing your learning rhythm. Its demerits are that it costs, the curriculum may not fit you, and there's a risk of being satisfied just by "attending."

In this article, I will not push a specific company as "this one's the best." Even when considering a school, it's healthy to look at comparison axes like cost, duration, scope of support, the domains you can learn, and self-driven vs. paced. When you want to compare by concrete service names, line up several and consider them fairly.

And judgments directly tied to money and jobs — career-change guarantees, refund guarantees, cost-effectiveness — are outside this article's scope. This article places no affiliate links or funnels to specific products. As a neutral guide to learning, it flatly provides only material for your judgment.

Growing through continuation and connections with people (the core of passed.jp)

This is the section this site most wants to treat richly. More than the technology itself, whether you can hold "systems for keeping going" divides those who grow from those who vanish midway. And the fuel for continuing can be made by "design," not by pep talk.

Here are concrete systems for keeping going.

Make output a habit. Write down what you learned, even briefly, and share it. Trying to explain it to someone reveals the holes in your own understanding. Writing is the easiest, most powerful review.
Study logs and looking back. Record "what you did" and review it regularly. When the accumulation is made visible, that itself becomes a motive to continue (the flip side of give-up point 4).
Join a community, study group, or co-working session. Even in moments where you'd break alone, you can dig in when people facing the same direction are beside you. "Keep going in front of others even if clumsy" grows you faster than "perfect, alone" — that's this site's stance.
Connect with a mentor or a senior. A relationship where you can ask someone walking a little ahead makes up for the "can't notice when your direction drifts" problem that tends to be self-study's weak point.
Solidify understanding by teaching each other. Explaining to someone who started after you organizes your own understanding to a surprising degree. Teaching is one of the best forms of learning.

Motivation has waves. This isn't because your will is weak; it's a matter of course. That's exactly why, rather than trying to ride the waves with "grit," you ride them with systems — that's passed.jp's consistent stance. (Concrete moves for rebuilding with systems rather than willpower when your progress stalls are written up in When Your Studying Stalls: Restart With Systems, Not Willpower.) Systems have, for example, the following empirically known nudging effects (spoken of more as felt experience than as strict academic terms).

The deadline effect … It's often said that deciding "by when I'll present this" makes people easier to move. A presentation slot at a study group is the prime example.
Social commitment … The nudge that declaring "I'll do it" in front of others makes it awkward to back out, so you keep going more easily.
The feedback loop … Once the loop of build → show → get a reaction → fix starts turning, learning tends to accelerate.

Connecting with people through growth is itself the fuel for keeping going. Getting better looks like a lonely task, but in fact it accelerates within "connections" — hold this view of improvement not as pep talk but as these concrete systems.

Summary: the first step to start today

Finally, let me compress the whole into one page.

The road from zero to engineer is six steps: (1) basics / foundation → (2) choosing a language → (3) framework → (4) Git / dev practice → (5) portfolio → (6) continuation. The order has meaning, and not skipping the foundation lets you proceed faster and less brittlely in the end.

And let me leave the smallest actions you can take today. You don't need to start big.

Install an editor (the software you write code in) on your computer
Build just one screen with HTML, even a single one
Write your study log, just one line
Register for one community or study group that interests you

With these four, you can start today.

What I want you to prioritize most is not "a design to finish fastest," but "a design you can keep going with." The one you're racing on speed isn't others; your point of comparison is yesterday's self. When you're about to break, come back to this article's "give-up points" section.

Once more, let me place the caveat again. Every number in the body — study hours, percentages — is an "estimate." When you use a concrete number to make a decision, always check its source and as_of (reference point), and don't swallow a single number whole.

Even once you've built the foundation and become able to self-drive, learning has no end. Whenever you're about to break, come back to this map anytime. And above all — start today, by opening your editor.