From never having programmed to understanding algorithms

Thirty-six weeks, ten hours a week, in Python. The first twelve weeks teach you to program at all. The remaining twenty-four teach you how data is organised and how algorithms work. Every technical word is defined the first time it appears — click any underlined term to see what it means.

36 weeks10 hrs / weekPythonNo prior experience

Part one — learning to program

Nothing here assumes you have written a line of code before. By the end of week 12 you will have built about twenty small programs and will be able to write a class from a blank file.

Week 0Getting your computer readyInstall the two pieces of software you will use for the next nine months, and prove they work.About 2 hours, before the clock starts Weeks 1–3Telling the computer what to doStoring information, making decisions, and repeating work. These three ideas sit underneath every program ever written.About 30 hours Weeks 4–6Reusable steps, and Python's built-in containersPackaging work into functions, and the four ways Python stores collections of things: lists, dictionaries, tuples and sets.About 30 hours Weeks 7–9Reading crashes, working with files, and finding bugsHow to read an error message instead of panicking, how to save and load data, and how to work out why a program is doing the wrong thing.About 30 hours Weeks 10–12Building your own kinds of thingClasses let you bundle information together with the actions that work on it — and one object holding a reference to another is the idea every data structure ahead is built from.About 30 hours

Part two — data structures and algorithms

The same skills, applied to the question of how to organise information so that programs stay fast as they grow. This half is where the well-known names live: hash tables, trees, graphs, sorting, dynamic programming.

Weeks 13–14How to say whether code is fastA vocabulary for describing how badly a program slows down as its input grows — and a proper look at recursion.About 20 hours Weeks 15–19Structures that lay things out in a lineArrays, linked lists, stacks, queues and hash tables — the workhorses. Build each one yourself, then use the built-in version forever after.About 50 hours Weeks 20–25Trees and graphsStructures that branch instead of running in a line. This is the hardest stage in the roadmap and deserves the extra time.About 60 hours Weeks 26–30The classic algorithmsSearching, sorting, and the graph algorithms behind route-finding and dependency resolution.About 50 hours Weeks 31–34Choosing the right approachThe previous stages gave you tools. This one is about recognising which tool an unfamiliar problem calls for.About 40 hours Weeks 35–36 and beyondOptional depthSpecialised structures and ideas worth knowing about. Treat this as a menu, not a checklist.About 20 hours, then ongoing

Rules that apply the whole way through

Type every example yourself

Do not copy and paste, and do not just read. Watching someone code feels like learning and is not. The gap between understanding a video and writing code on a blank screen is the entire skill, and copying skips exactly the part that builds it.

Build each structure once, then never again

Implement every structure from scratch a single time, so it stops being magic. After that, use the version that ships with the language — it is faster and it has had its bugs found already.

Thirty minutes before you look at a solution

Struggling is the part that teaches. Reading a solution before you have genuinely tried feels efficient and leaves nothing behind.

Keep a mistake log

Write down the problem, why you failed it, and the pattern you missed. Read it back weekly. This is the highest-value habit in the whole roadmap, and the one most people skip.

Done means from a blank file

A topic is finished when you can re-implement it with nothing in front of you, and say what it costs in time and memory. Recognising code is not the same as being able to write it.

Six hours learning, four hours solving

Of ten hours a week, roughly six go on learning and implementing and four on problems. Reading without solving is the single most common way people spend months and gain little.

What ten hours in a week looks like

When	Hrs	What you do
Mon–Tue	3	New topic: read and watch, then write notes in your own words.
Wed	2	Implement the structure or algorithm from scratch, with nothing to refer to.
Thu–Fri	3	Solve four to six problems on the topic, working from easy up to medium.
Sat	1	Re-solve two problems you previously failed, taken from your mistake log.
Sun	1	Review: say the costs out loud, update your notes, plan the week ahead.

An honest note on the timeline

About eight to nine months at ten hours a week to reach the end of week 34. That is a normal, honest timeline starting from zero. Anyone promising mastery in eight weeks is selling something.

The week numbers are a guide, not a deadline. Two stages in particular — trees and graphs in weeks 20 to 25, and dynamic programming in week 31 — are where most people slow down or give up. If you fall behind, take the extra weeks there rather than skipping ahead. Everything later depends on those two.

This roadmap is written for becoming a better engineer rather than for passing interviews. Where the two differ, it favours understanding fewer things properly over covering more things quickly.