How Long Does It Take to Learn Coding? The Three Horizons

Ask how long it takes to learn coding and you will get numbers between six weeks and ten years, all delivered with total confidence.

They are not contradicting each other. They are answering different questions and not saying which one. "Learned to code" can mean you automated a spreadsheet on a Sunday, or that a company pays you to own software in production. Those are separated by a factor of roughly twenty in hours.

So the first useful move is to stop asking how long it takes and start asking which finish line you meant.

Everything below is a planning estimate, in our own voice, from watching a lot of people do this. Treat these bands the way you would treat a renovation quote: useful for deciding whether to start, not a promise, and heavily dependent on choices you have not made yet.

What is not an estimate is the structure. There really are three horizons, they really do arrive in this order, and most people who give up were aiming at the second one while measuring themselves against the first.

Three things get called "learning to code," and they are as different from each other as jogging is from marathon training.

Useful to yourself. You can make a computer do something you wanted done. The bar is a working script, not clean code.

Hireable. A stranger will pay you to write software that other people depend on. This bar is set by the market, not by you, and it includes a great deal that has nothing to do with writing code.

Fluent. You can look at an unfamiliar system, form an opinion about how it should be shaped, and be roughly right. This one is not measured in hours at all.

Confusing the first with the second is the most expensive mistake in the subject. It is why someone who genuinely wrote a working program in six weeks tells you coding is fast, and someone eighteen months into job applications tells you it is brutal, and both are being honest.

Plan for roughly 50 to 100 hours. At an hour a day that is two to three months; at a focused weekend pace, a few weeks.

At the end of it you can read a file, loop over it, transform the contents, handle the case where something is missing, and write the result somewhere else. You can call an API. You can automate the thing at work that everyone does by hand.

This horizon is genuinely reachable and genuinely underrated. It is also the one every course is optimized to deliver, which is why the early experience feels so fast. The concept order for this stretch is laid out on the programming fundamentals page, and the honest warning is that the pace you set here does not extrapolate. Nothing about the next horizon behaves like this one, for reasons we took apart in is coding hard to learn.

Budget roughly 800 to 1,200 hours of deliberate practice, and expect most of it to be spent on things that are not language syntax.

Translate that into calendar time and the ranges get uncomfortable. Ten hours a week is around two years. Twenty-five hours a week is closer to one. Full-time and focused, with no other job, is somewhere in the six-to-twelve-month band — and that last version is the one every advertisement quotes while omitting the words "full-time."

What fills those hours is the surprising part. Perhaps a fifth is learning the language. The rest is version control, project structure, testing, databases, HTTP, debugging things you cannot reproduce, reading code you did not write, deploying, and then the entirely separate skill of interviewing — which has its own hundred hours attached and resembles the job about as much as a driving test resembles a commute.

Several thousand hours, and the number stops being the point.

Fluency is gated by exposure to consequences, not by study time. It arrives after you have owned something in production long enough to watch it break in ways you caused, made an architectural decision you regretted eighteen months later, and inherited a codebase from someone who has left the company. None of those can be accelerated by working harder this week. They require elapsed time and real stakes, which is why the first year of a job teaches more than the two years of preparation before it.

This is worth knowing early for one reason: you do not need horizon three to get hired. Aiming at it before you have a job is the most common way people delay applying for a year they did not need to spend.

Take the middle of the hireable band — call it a thousand hours — and divide by the schedule you can honestly sustain. These are the calendar figures nobody puts in a course description.

• Five hours a week (an hour on weeknights): roughly four years. Slow, and still the right choice over quitting.
• Ten hours a week (evenings plus part of a weekend): roughly two years. This is the most common real-world pace for someone employed full-time.
• Twenty hours a week (serious side commitment): a little over a year.
• Forty hours a week (full-time, no other job): six to nine months, plus interview preparation on top.

Two notes on reading this list. Sustainable beats ambitious every time, because the schedule you abandon in month three produces zero hours from month four onward. And pick the row you can hold for a year, not the row you can hold for a fortnight.

Every timeline in this article assumes a kind of hour that most people are not actually logging.

Composition. Five hundred hours of watching tutorials and five hundred hours of building are not interchangeable, and it is not close. Ericsson's research on deliberate practice found that improvement tracks practice at the edge of your current ability, with feedback, and that comfortable repetition produces long plateaus. Coding along with a video is comfortable repetition. If you want your hours to count at the rate these bands assume, they have to be hours where you might fail.

Distribution. The same hours spread out beat the same hours stacked up. The spacing effect is one of the most reproduced results in learning research, and the forgetting curve explains why: memory decays predictably, and the fix is meeting the material again after some of it has faded. This has a blunt consequence for anyone planning a sprint. You cannot compress eight hundred hours into eight weeks and keep them. You can be exposed to that much material. You will not retain it, and the retention is the thing you were buying. Even a short daily habit outperforms weekend binges, which is the argument in learning a skill in fifteen minutes a day.

Three months of full-time study is around 500 hours. That is real progress. It puts you inside horizon two, and for a small number of people with adjacent experience and a warm network, it has been enough.

It is not the median outcome and it never was. Two things get left out of the pitch. The first is arithmetic: 500 hours is roughly half of the band above, and the missing half is the engineering half — testing, structure, debugging, deployment — which is exactly what an interviewer probes and exactly what a bootcamp curriculum has the least room for.

The second is the market. The people for whom twelve weeks worked were mostly hired in a period when companies were absorbing junior engineers at a rate that no longer holds. AI coding tools have since taken over a large share of the routine implementation work that used to fill a new hire's first year, which has made senior demand hold up and entry-level competition much sharper. That does not close the door. It does mean you need more demonstrated ability than the previous cohort needed, and that a portfolio of course projects is now the floor rather than the differentiator.

None of this is an argument against starting. It is an argument against planning your finances around a twelve-week timeline.

Four things reliably move people faster, and none of them is studying more hours per week.

Pick one language and stop reconsidering. Every switch costs you the compounding and buys you nothing, because concepts transfer and only syntax does not. The endless-restart loop is the single biggest silent tax on self-taught timelines, and it has its own diagnosis in why you keep starting over.

Move to projects earlier than feels responsible. The instinct to finish the fundamentals first converts study hours into low-yield hours. Start building while you still have gaps; the gaps close faster from above.

Get an external correction loop. Code review, pull requests to strangers, a mentor, mock interviews. Without feedback you plateau while still logging hours, which is the exact failure Ericsson describes.

Enter through the widest available door. Support engineering, QA, internal tooling at your current employer, contract work. Being paid to be near software compresses horizon two dramatically, because you get consequences instead of exercises.

If your own timeline is running long, it is almost certainly one of these rather than a shortage of effort. They are worth naming because each one feels productive from the inside, which is the only reason anyone stays in them for a year.

Restarting the fundamentals. The third pass through variables and loops is not revision, it is avoidance of the part that got hard. Every restart resets the clock while feeling like diligence.

Course collecting. Finishing material is a measurable, pleasant activity with a completion bar. Building is ambiguous and has no bar. People drift toward the measurable thing and mistake the metric for the goal.

Waiting to feel ready. Readiness is not a feeling that arrives. It is a fact other people determine, usually about six months before you would have volunteered.

Studying in bursts. A nine-hour Saturday after a dead week is worse than ninety minutes a day, for reasons the forgetting curve makes unavoidable.

For someone with an hour a day and no technical background: a couple of months to write something genuinely useful to yourself, and plan on one to two years to reach the hireable line — the lower end if you get real projects and real feedback early, the upper end if you spend the first year in courses.

For someone going at it full-time with focus: weeks to the first horizon, and six to twelve months to the second, with the interview preparation counted separately because it is a separate skill.

Both numbers are wrong for you specifically, and both are close enough to plan with. The variable that moves them most is not your intelligence and not your hours per week — it is what fraction of those hours you spend somewhere you might fail. If you want the practice structure that makes hours count, that is what the whole learning-to-code path is built around.

Start the clock on a real project this week and the estimate stops mattering.