It depends entirely on what you mean by “learn”, so here is the useful version of the answer:
- Write and run your first program: under an hour.
- Write a small program from scratch, no tutorial open: roughly 20–40 hours of practice.
- Finish a first real project: roughly 60–100 hours.
- Comfortable in one language: roughly 200–400 hours.
- Able to find your way around code you did not write: 600 hours and up.
Those are hours of practice, not hours of watching. The difference between the two is most of why people’s timelines vary so wildly.
The milestones, in more detail#
Hour 1 — your first program runs#
You install something, type three lines, and the computer responds. This is a real milestone and worth marking, because a surprising number of people never get past the setup. See your first Python program.
Hours 20–40 — you can write something small unaided#
You know what a variable, a condition, a loop and a list are, and you can combine them without a tutorial open. It still takes you a while, you still look up syntax constantly, and that is fine — professionals look things up daily.
This is where most people who quit, quit. The novelty has worn off and you are not good yet.
Hours 60–100 — a finished project#
Something with more than one part that does something useful, built by you, finished rather than abandoned. A to-do app that saves its data, a script that tidies a folder, a page that fetches and displays real information.
Finishing is the skill here, more than any particular technique. See beginner programming projects worth finishing.
Hours 200–400 — comfortable#
You can plan a small program before writing it, you recognise most error messages on sight, and getting stuck feels routine rather than alarming. You have opinions about how to structure things.
Most people reach roughly this point somewhere between six months and two years, depending almost entirely on consistency.
Hours 600+ — you can work on someone else’s code#
Reading unfamiliar code, following it, and changing one thing without breaking three others. This is a genuinely different skill from writing your own, and it is the one that matters most in real work.
The same hours, in weeks#
Hours are honest but abstract, so here is what they look like at three realistic paces.
| Milestone | 5 hrs/week | 10 hrs/week | 25 hrs/week |
|---|---|---|---|
| Small program unaided (~30 hrs) | 6 weeks | 3 weeks | ~1 week |
| First finished project (~80 hrs) | 4 months | 2 months | 3 weeks |
| Comfortable (~300 hrs) | 14 months | 7 months | 3 months |
| Reading unfamiliar code (~800 hrs) | 3 years | 18 months | 8 months |
Treat these as rough shapes, not promises. Two people at the same hour count can be in very different places depending on what those hours contained.
The four things that actually change the timeline#
1. Consistency beats intensity#
One hour on five days beats five hours on one day, by a wide margin. Programming builds on itself, and long gaps mean re-learning rather than progressing. Thirty minutes most days genuinely outperforms a heroic weekend every fortnight.
2. Building beats watching#
This is the big one. Someone who spends 100 hours building small things will be far ahead of someone who spent 100 hours following along with courses, even though both “put in 100 hours”.
Watching is comfortable because someone else makes every decision. Making those decisions yourself is the actual skill. Aim for roughly one hour of learning to three hours of building — see how to practise so it sticks.
3. One language, for a while#
Switching languages every few weeks resets you to the confusing part each time. Pick one and stay with it until you can build something end to end. Your second language will then take a fraction of the time, because the hard part transfers. See choosing your first programming language.
4. Being able to get unstuck#
The gap between someone who progresses quickly and someone who stalls is usually not talent — it is whether they can read an error message and work out what to try next. It is a learnable skill and it compounds, because every hour after you learn it is more productive.
Start with how to read programming errors.
Why “three months to a job” is misleading#
You will see this claim constantly. It is not exactly a lie — some people do go from zero to employed in months — but it leaves out things that matter:
- Full-time is doing the heavy lifting. “Three months” usually means 40+ hours a week — around 500 hours. At five hours a week, the same 500 hours takes two years.
- The people quoted are often not starting from zero. Prior technical work, a maths or engineering background, or a previous attempt years ago all count and are rarely mentioned.
- Survivorship bias. You hear from the people it worked for. The ones who finished the same course and did not get hired do not write posts about it.
- Hiring is not a function of your skill alone. The market that year, your location, your network and timing all matter, and none of them are things a course can promise.
None of this means it cannot happen. It means the number tells you about someone else’s circumstances, not about yours.
How to tell you are actually progressing#
These are the signals worth watching, roughly in order:
- You can guess the cause of an error before reading past the first line
- You look things up for specifics rather than for basics
- You can read code you wrote last month and follow it
- You can start a blank file and make something small without a tutorial
- You start noticing what is bad about your own code
- Getting stuck feels like a normal part of the work
If none of those are moving after a few months, the problem is almost always the balance — too much input, not enough output. Build something small this week instead of watching another course.
Does age or background matter?#
Not in the way people worry about. Programming is built by repetition, not by a talent you either have or do not. People start in their teens and in their fifties and get good at it.
Background helps at the margins — a maths background makes some areas easier, previous technical work makes the tooling less strange — but it changes the slope, not whether the hill can be climbed.
Questions people ask#
Can I learn programming in a month?
You can learn the fundamentals and write small useful programs in a month of consistent daily practice. You will not be comfortable across a whole area in a month, and that is normal rather than a failure.
How many hours a day should I do?
One hour most days is a strong, sustainable pace. Two is better if you can hold it without burning out. More than four is usually diminishing returns for a beginner, because the ideas need time to settle.
Is it too late to start?
No. The only thing age changes is how much time you have spare, which affects the calendar, not whether it works.
Do I need a computer science degree?
No. It helps for some roles and is irrelevant to others. What consistently matters is whether you can build things and explain how they work. See how to build a programming portfolio.
Should I pay for a bootcamp to go faster?
A bootcamp mainly buys structure, deadlines and other people, which some people genuinely need and others do not. It does not remove the hours, and no course can guarantee an outcome that depends on the job market. If you would practise consistently without one, free material will get you to the same place.
How long until I can build something people actually use?
Sooner than you would expect for small tools — a script that automates something annoying is achievable within a couple of months, and that is a real thing people use. Larger applications with other people’s data are a much longer road.
Where to go next#
- How to start coding from scratch — a realistic first month, week by week
- How to practise programming so it sticks
- Learning time calculator — these estimates at your own weekly pace
- Start here — the full ordered path