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

This is a learning roadmap for people starting from zero toward becoming an engineer. It lays out what to learn, in what order, and roughly how much, in six steps: build a foundation, choose one language, get one framework running, learn Git and development practice, build a portfolio, and keep going through systems. Alongside that path, passed.jp covers the seven places where people commonly give up and how to get past them, plus six neutral axes for choosing between self-study and a school.

It is written for complete beginners, working adults or students, and for anyone who has just started and is stuck at "I don't know what to do next." By the time you finish, you should have a full map in hand: 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 this article covers 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, or the reality of school guarantee programs. The goal is not the doorway to a job search. It is 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.

The goal of this roadmap is not memorizing a specific language. Languages and frameworks come and go. What you are aiming for is a state where you can look things up yourself, move your hands, and keep going. In short, you become able to "self-drive."

Here is how to read on. Start with the big picture (six steps). Then go through each step in order. After that, check your defenses against the give-up points, gather the material for judging self-study versus school by aptitude, and finish with the craft of keeping at it. Feel free to skim whichever section interests you. If this is your first time, reading top to bottom will make it clear why the order is what it is.

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

Learning from zero to engineer becomes far less bewildering when you split it into six steps. Because the timeline depends heavily on how many hours you can secure per day, this article gives no specific total and shows a way to work backward instead.

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 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 that you can think and build
Continuation: grow through systems for keeping going, and through connections with people

There is a reason for the order. Skip the foundation (step 1) and jump straight into a language or framework, and you keep freezing up. You cannot tell why an error appears or what a 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 are 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 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 with the hours you can put in each day. 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 this: you do not 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 acquire in STEP1 is not memorization but a whole-picture map of how computers and the Web work. Touch four things (HTML/CSS, how the Web works, the terminal, and a dev environment) and you have the foundation for every later step.

Here are the 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. Build a simple one-page site with your own hands, and you will feel that a web page is not magic. It is a stack of instructions.
Know the broad outline of how the Web works. A browser (the client) asks a 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 in later study connect.
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 (the terminal). Leave a mental block here, and it will hold you back for a long time.
Set 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.

The countermeasure is knowing options that reduce environment differences. For example, there are cloud-type dev environments that run entirely in the browser. There is also container technology that reproduces a whole environment inside a box. These make you less likely to get pushed around by mysterious errors that only happen on your machine. There is no single right answer. What works most here is simply knowing that if you get stuck, you have an escape route: try a different environment.

The time this step takes varies by person. The trick is to proceed with the attitude 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 while advancing the later steps.

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

Choose your first language by working backward from what you want to build, and narrow it to one. There is no "strongest language." A language is a tool, and you choose a tool by what you want to build.

The easiest trap here is getting hooked on the question "which language is strongest." 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 thick 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 is healthy to view each language fairly on axes like the domain it suits, the thickness of its 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. It shifts with the times, so it is safer to consult primary sources than to assert.

What a beginner should keep in mind first is the policy of "one language 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 come by. Narrow to one first, and stack up the success of "I built something that runs" in that language. That tends to grow you faster in the end.

You may worry: "If I narrow to one, what if I can't adapt later?" Rest assured. The foundation of programming (the ideas of variables, conditionals, loops, functions, and data structures) is common across languages. Understand one deeply, and moving to a second or third language is not as hard as the first. That is exactly why it is worth choosing 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 have touched the basic grammar of a language, the framework comes next. Pick just one representative framework for your chosen language, and build something small but working, all the way to the end. That is the goal of this step.

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, which is why it is used as standard in real work too.

Here are the representative ones, laid out 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; if 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. An ecosystem is the collection of tools and information gathered around it. You don't have to distinguish them perfectly at this stage. As you run a small app on one framework, the outlines come into view on their own.

The time it takes varies a lot by language, framework, and the hours you can secure, so treat it only as an estimate here too. The goal is not keeping to a schedule. It is reaching the state of "with one framework, I built something that runs with my own hands."

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

STEP4 covers the foundational skills of version control, working the terminal, databases and SQL, APIs and HTTP, and deployment. Run the flow of "build → version-control → publish" all the way through even once, and the quality of your learning changes.

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, then slowly takes effect after you're hired.

Here are the skills that become the foundation on the job.

Version control (Git / GitHub): a mechanism that records the change history of your 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 from 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 where you re-understand STEP1's Web mechanism more concretely.
Simple deployment (publishing): taking something that runs only on your own machine and publishing it online so others can touch it.

What I 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 run this whole sequence with your own hands changes the quality of your learning greatly.

The conventions of team development are also enough to just know about at this stage. For example, there is the culture of not putting a change straight into production but having it reviewed first. There is also the practice of writing out what needs doing as issues and managing them. After you're hired, you'll come to understand their meaning in your body. In our editorial view, beyond the ability 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. Its purpose is to show "I can think, and I can build." Build one small app that solves a problem of your own, and publish it with a README that explains the background, your ideas, and where you got stuck.

For what to make, skip the "clone" that copies a famous existing app. Instead, 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 even at a small scale.

What makes a portfolio land is not the number of features or flashy looks. It is whether you can put into words why you built it, where you got creative, where you got stuck, and how you solved it. Write the following in the README (the file that explains the project), and the value of what you made comes 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 publishing, 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 is "one, deep" over "make many." Rather than lining up several shallow ones, building one properly, stuck parts included, conveys far more.

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 is itself the greatest learning. Making a portfolio mobilizes everything 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

The places where beginners break cluster into seven: environment setup, errors, loneliness, invisible progress, perfectionism, lack of time, and comparing yourself to others.

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 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 the choice of tools, not by grit.
Error messages are scary and unreadable. → An error isn't a scolding. It's a hint telling you where the problem is. Search the wording of the message (especially the English line) 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, with no one to ask. → Belong to even one of the communities or study groups mentioned later. Just having a place to ask makes 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 while trying to write beautiful code from the start, run it first and fix it later. Learning moves faster that way too.
Can't secure study time. → Drop it into habit instead of relying on motivation. Get through with design: fix the time slot, or decide on just 15 minutes in the morning. Systems last longer than willpower.
You lose confidence comparing yourself to others. → Compare yourself to your past self. Other people's progress 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." 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 structure of why self-study breaks, and concrete ways to rebuild it with systems, are gathered in When Self-Taught Programming Won't Stick: Six Systems to Rebuild Without Willpower.

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

Neither is above the other. You choose by your own aptitude. Judge on six axes: cost, ease of securing study time, personality, an environment to ask questions, recovery power when you stumble, and whether you want knowledge or support.

Here are the axes for the judgment, laid out symmetrically.

Cost: Self-study is easy to keep cheap. A school costs, and in exchange you buy an 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. 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: cost stays low, and you can dig deep at your own pace, wherever your interest leads. Its demerits: 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: a systematic curriculum, an environment to ask questions, peers with the same goal, and an externalized learning rhythm. Its demerits: 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." When considering a school, look at comparison axes like cost, duration, scope of support, the domains you can learn, and self-driven versus paced. When you want to compare by concrete service names, line up several and consider them fairly.

Judgments directly tied to money and jobs, such as career-change guarantees, refund guarantees, and 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)

What divides those who grow from those who vanish midway is not the technology itself. It is whether you hold systems for keeping going. And the fuel for continuing can be made by design, not by pep talk.

This is the section this site most wants to treat richly. 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.
Keep a study log and look back. Record what you did and review it regularly. When the accumulation is visible, that itself becomes a reason 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 is 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 self-study's typical weak point: not noticing when your direction drifts.
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. That isn't because your will is weak; it's simply how it goes. That's exactly why you ride the waves with systems, not with grit. This is passed.jp's consistent stance. Concrete moves for rebuilding with systems rather than willpower when your progress stalls are written up in How to Restart When Your Studying Plateaus: Three System-Based Steps That Don't Rely on Willpower.

Systems come with nudging effects that are empirically well known (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: 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

Keep the six steps in order, and start with the smallest actions you can take today. That is the first step. You don't need to start big.

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. Not skipping the foundation lets you proceed faster, and with less breakage, in the end.

Here are the smallest actions you can take today.

Install an editor (the software you write code in) on your computer
Build just one screen with HTML
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." You aren't racing anyone else on speed. 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 can self-drive, learning has no end. Whenever you're about to break, come back to this map. And above all: start today, by opening your editor.

FAQ

Q. How many hours of study does it take to become an engineer from zero? A. This article gives no specific total. The premises (target language, the level you're aiming for, learning efficiency) differ completely by source, and the range is enormous. Instead, work backward from the hours you can secure per day. If you want a concrete figure, check multiple primary sources together with their as_of (reference point).

Q. Which programming language should I learn first? A. Work backward from what you want to build, and narrow it to one. JavaScript / TypeScript for the web frontend; Ruby, PHP, Python, Java, Go, and so on for the backend; Python is often used for data, AI, and machine learning. There is no "strongest language," so pick the one closest to what you want to build.

Q. I'm stuck on environment setup and can't move on. What should I do? A. Reduce environment differences with a cloud-type dev environment that runs in the browser, or with container technology that reproduces a whole environment. Knowing that you have an escape route (try a different environment) is what works most here. It's a domain solved by the choice of tools, not by grit.

Q. How many portfolio projects should I build? A. "One, deep" beats "make many." Build one small app that solves your own trouble or a nearby problem, write the background, your ideas, and where you got stuck in the README, and publish it on GitHub with a working deployment.

Q. Should I choose self-study or a school? A. Neither is above the other; choose by aptitude. Judge on six axes: cost, ease of securing study time, personality (self-driven or paced), an environment to ask questions, recovery power when you stumble, and whether you want knowledge or support. This article pushes no specific company and places no affiliate links.