Dev Learning Path

The path from knowing nothing to contributing on a real software project — as two tracks that run in parallel and reinforce each other. Neither replaces the other.

The two tracks

Choosing your build curriculum

Track A, stage 3 is the one that matters most — and it's not "just projects": a good curriculum teaches HTTP, Git, databases, frameworks, testing, and deployment interleaved as a build needs them, which is why those layers never show up as their own line. Three clear the bar; here's what each actually contains, from their live syllabi. For which specific course to pick per language or framework — Python, Java, JavaScript, React, FastAPI, Spring Boot — see Course Picks by Language & Framework →.

How to trust a path

Spot a proven resource

Don't judge the content on its face — judge the signal around it. Battle-tested resources share these:

1. Convergence — in multiple communities' recurring consensus, and A/B'd head-to-head against the other leaders ("X vs Y"). That mutual comparison is the proof — nobody compares a random tutorial to a leader. A single page or a unique take nobody echoes fails this outright.
2. Named authority — a university, established nonprofit, or known practitioner. Anonymous = discount heavily.
3. Open correction — lives where errors get fixed (a GitHub repo with issues/PRs, an active forum). A static blog can't self-correct.
4. Reproduction / survivorship — thousands of documented completions and "I did this and got hired" stories. A path nobody finished is unproven.
5. Incentive check — free/nonprofit, or at least not a funnel into a $12k bootcamp. Follow the money.
6. Currency rule — fundamentals age slowly; tooling and framework guidance must be recent.

Red flags: "learn X in 24 hours," 30-minute certificates, covers every topic shallowly, no named author, ad-choked. Content farms rarely cite credible authorities — that's the tell.

Earn confidence — validate backwards from the gate

Picking the "best" path up front is low-leverage — the evidence says the specific curriculum barely predicts outcomes. Confidence is earned by testing against the real end-goal, early and often.

Then shorten the feedback loop to that gate — ranked by signal:

1. Use a real job as the validator — an internship or job is the destination. Perform, watch what code reviews flag, notice what teammates take for granted. No course beats it as a signal.
2. Mock interviews (interviewing.io, Pramp) — measured directly against the gate, and the single strongest predictor in the data. Start before you feel ready; the reps are the prep.
3. Ship a real project, get a senior to review it — tests the "can you build" gate against a person already at the destination.
4. Read the gate specs — target companies' job postings and their public interview processes. The literal end-state, written down.

Base rates over anecdotes: weigh audited outcome data — interviewing.io, the Stack Overflow Developer Survey, CIRR bootcamp placement — over any single success story. And when copying what top-placing programs do, copy the causal levers (intensity, project volume, gate-targeted interview prep, a networked job search) — not the brand. Their headline rates are inflated by selective admissions.

Quick reference — every source

Everything above, in one place — each solves a different slice.

Go deeper

Learning CS System → — my detailed notes, protocols, and course-coverage analysis for the Understand-the-machine track (DSA, fluency, university curricula).

Course Picks by Language & Framework → — choosing a build curriculum? This ranks what the community actually recommends most for Python, Java, JS, React, FastAPI, and Spring Boot by independent evidence — the same "how to trust a path" method applied per technology.