Milestone map
Milestone map
3 milestones
Complete a Structured Curriculum and Build a Running Program
6–12 weeks (1–2 hrs/day)
Choose a programming language and a structured free curriculum (CS50P, freeCodeCamp Python, the official Python tutorial, or equivalent). Complete all core exercises. Then build one self-contained program that does something you actually want — a script that automates a task you do manually, a command-line tool, or a simple game. The program must run without errors on someone else's machine following your instructions.
Proof required
Submit: a GitHub repository (public or shared) containing your program's source code and a README with installation instructions and example output; a screenshot or video of the program running; and a completion certificate or progress screenshot from the curriculum you chose. The README must allow a stranger to run the program without asking you questions.
What gets checked
- Program runs on a clean machine following the README — if the README requires asking the submitter for clarification, it is incomplete
- Program does something genuinely useful or interesting to the submitter — 'hello world' or a tutorial exercise submitted verbatim does not count
- Curriculum completion evidence is real: a certificate, a progress page showing ≥80% completion, or a screenshot of a final project grade — a self-report of 'I finished it' is not sufficient
Common mistakes
- Choosing a language or curriculum and abandoning it when it gets hard — the M1 proof requires following one structured path through, not hopping between tutorials
- Building a program that only runs in the development environment because of hardcoded paths or untracked dependencies
- Submitting tutorial exercise code as the 'program' — the program must be something the submitter conceived, not an exercise from the curriculum
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Run the program from the README on a clean machine — if it fails or requires clarification, note that specifically in the review
- Ask the submitter to explain what a specific function in their code does — a confident explanation in their own words confirms authorship
- Ask what the hardest part of the program was to build — vague answers suggest the submitter did not write it themselves
- Ask what the curriculum's final project was and why they chose their own program topic — there should be a clear personal motivation
You'll sign in first, then come straight back here.
Build a Self-Proposed Project for a Real User
4–8 weeks (2–3 hrs/day)
Identify a real problem someone (yourself, a friend, a colleague, a community) has, and build a program that solves it. The program must go beyond scripts: it should handle multiple inputs, store or retrieve data (a file, a database, or an API), and produce useful output. Get the program into someone else's hands and document their feedback. Write a 200-word reflection: what you tried to build, what you cut, and what you learned that you could not have learned from exercises.
Proof required
Submit: the GitHub repository with source code and README; evidence of the real user (a message, a screenshot of them using it, or their written feedback); and your 200-word reflection naming what you cut from the original plan and one thing you would do differently now.
What gets checked
- Real user evidence is specific: a message, screenshot, or feedback note from a named person — 'my friend used it' without evidence does not count
- Program handles more than one type of input or user scenario — a script with a single hardcoded input path is not a project
- 200-word reflection names something you cut and explains why — a reflection that only describes what was built has not addressed the prompt
Common mistakes
- Building for a hypothetical user rather than a real one — the user evidence requirement exists precisely to force real deployment
- Scoping the project so large it never ships — a working small program delivered to a real user is worth more than an unfinished ambitious one
- Treating the 200-word reflection as a description of the program rather than an honest account of what was cut, what broke, and what was learned
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask the submitter to describe the real user's reaction — what did they find useful and what confused them?
- Ask what the original plan included that was cut — the absence of any cuts suggests the project was scoped after the fact
- Run the program using the README — if it requires the submitter's help to run, the README is insufficient
- Ask what they would build differently if they started over — a specific answer shows genuine learning; 'nothing' suggests the reflection was superficial
You'll sign in first, then come straight back here.
Defend Code and Design Choices to an Experienced Developer
1–2 weeks (scheduling and completing the session)
Arrange a live 45-minute code review with a developer who has at least 3 years of professional experience and does not know your project already. Walk them through your M2 project: explain your design choices, show the code, and answer their questions without referring to notes for the logic. The reviewer will ask 'why did you choose X over Y?' and 'how does this part actually work?' questions you cannot pre-script. Document the session: who reviewed it, their qualification, what they specifically suggested changing, and what you did or plan to do about it.
Proof required
Submit a session record containing: the reviewer's name and a verifiable credential showing 3+ years of professional programming experience (LinkedIn or GitHub profile URL); a summary of at least two specific design questions they raised; and a 200-word reflection on the most important thing the review changed about how you think about code.
What gets checked
- Reviewer credential is verifiable and shows professional programming experience of 3+ years — a senior student or hobby coder is not sufficient
- Two specific design questions are documented: not 'they asked good questions' but the actual question and your answer
- 200-word reflection names a specific change in thinking — not just 'I learned a lot' but a concrete shift in how you approach a specific problem
Common mistakes
- Choosing a reviewer who is a fellow learner or peer — the session needs someone who can recognise poor design choices you are not yet aware of
- Preparing a scripted demo rather than a live walkthrough — the reviewer must be able to ask about any part of the code, not just the parts you rehearsed
- Treating the post-session reflection as a summary of what you did rather than what the review changed — if it was a real review, something changed
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the reviewer credential is current and shows real professional experience — check that the LinkedIn or GitHub profile is active and shows a programming role, not just a claimed title
- Ask the submitter to repeat one of the reviewer's specific questions from memory — if they cannot, the session details were likely reconstructed after the fact
- Ask what the reviewer said about the biggest design weakness — every experienced reviewer identifies something; 'they said it was good' without a critique is a red flag
- Ask what they changed about the code or their thinking after the session — some change, however small, is expected from a real review
You'll sign in first, then come straight back here.