Build real things

The task the canon forgot

Blind 75, NeetCode, Grind75, the handbook: not one of them asks you to build anything. Follow them to the letter and you arrive at day one of a real job having never deployed a server, never read a stack trace from production, never named anything that had to be renamed later. LeetCode-only prep produces a strange creature: employable, and unable to ship.

Career retrospectives keep converging on the same verdict from the other direction: side projects pay twice. Once as actual skill, and once as material, because every behavioural round you will ever sit ("tell me about a hard bug", "tell me about a technical decision you regretted") gets answered out of the things you built. Task 8 will draw directly on what you make here. An empty portfolio means empty answers.

So this task runs in parallel with the long middle: patterns on weekdays, building on the days your brain refuses another medium.

The tutorial-hell exit ladder

Tutorial hell is not a knowledge problem, it is a dependency problem: you have only ever written code while someone told you what to type. The exit is a ladder, and the rungs are doses of independence:

1. Guided. Follow a tutorial end to end. Fine, you have done plenty of these. This rung is behind you.
2. Semi-guided. Take the thing the tutorial built and change it meaningfully: add a feature it didn't have, swap the storage layer, break it on purpose and repair it. No instructions exist for your version. That is the point.
3. Unguided. Blank directory, your own idea, nothing to follow but documentation and error messages.

Three projects, escalating

Eight weeks, three deliverables. Each one is small enough to finish and real enough to hurt a little.

1. A CLI tool that fixes a real annoyance of yours. Something you personally will run next month: a script that renames your screenshots, tallies your bank CSV, checks whether your favourite site changed. Requirements: it has tests, and it has a README that a stranger could follow. The annoyance must be real, because real requirements are the thing tutorials can't simulate.
2. A web app, front to back. One page, one server, one database, deployed to a real URL that you can open on your phone. Auth optional, polish optional, deployment not optional. The gap between "works on my machine" and "works on a URL" is where half of practical engineering lives, and you only learn it by crossing it.
3. Rebuild project one in Go. Same tool, second language. You already know what it should do, so all your attention goes to how the new language thinks: explicit errors instead of exceptions, a type system that argues back, one obvious formatting style. A second language is the cheapest way to discover which of your habits were programming and which were just your first language's accent. The Go tour is the right amount of preparation; the Go study path is there when you want more.

Just enough web

Project two forces the question most study plans dodge: do you actually know what happens between a browser and your server? Three short reads cover the road: how DNS finds your server, how HTTP carries the request, and how HTTPS keeps it private. Read them while project two is in progress, when each one answers a question you currently have, instead of before, when they are trivia.

And learn enough HTML, CSS, and JavaScript to be dangerous. This plan is not a backend-only plan; "I don't do frontend" is a thing people say right up until the demo needs a page. MDN's Learn Web Development is the canonical on-ramp: skim the HTML and CSS modules, take the JavaScript one seriously. You do not need a framework for one page. You need a form, a fetch call, and the discipline to stop there.

Git beyond add, commit, push

Three commands memorised in week one of programming, plus panic-googling for everything else, is the standard git education. Project work is where you upgrade it, because now you have history worth protecting.

Start with what git actually stores: not diffs, but snapshots; a content-addressed object store where commits point to trees, trees point to blobs, and branches are just movable name tags on commits. Once that model clicks, the scary commands stop being incantations. rebase is "replay these commits onto a different parent". reset is "move the name tag". reflog is the proof that almost nothing is ever lost.

During these eight weeks, force yourself through one honest merge conflict, one interactive rebase to clean up a messy branch, and one recovery via reflog. The deeper end of the pool is Pro Git, chapter 10, "Git Internals", which is shorter than its reputation suggests.

Debugging as a discipline

Real projects produce real errors, which is most of their educational value. Two network errors in particular will find you during project two, so meet them on your own terms first: ECONNRESET, the peer hanging up mid-conversation, and EADDRINUSE, the port your crashed server never let go of. Both pages walk the actual diagnosis, not the Stack Overflow ritual.

Then go one layer down. The Linux path teaches the investigative loop that separates debugging from guessing, and "the box is slow" is the right first walkthrough: a complaint with no information in it, turned into a diagnosis through a fixed sequence of questions. That loop, observe, hypothesise, test the hypothesis cheaply, is the discipline. Printing variables until the bug confesses is not.

Keep a debugging log for these eight weeks: every bug that cost you more than thirty minutes gets three lines, what it looked like, what it was, what would have found it faster. This log is behavioural-round gold in task 8, written by past you.

What you walk away with

At the end of this task you have: a URL that works, and a repository you are not embarrassed by. Tests that run, a README that is honest, commits that tell a story, a tool you actually use.

To almost every employer, that artifact is worth more than fifty additional LeetCode problems, because it is evidence of the job rather than evidence of preparing for the job. The patterns from task 5 get you through the algorithm rounds; this gets you through "so, tell me about something you've built", and it is the only part of your preparation that survives contact with employment.

Further reading

• MDN — Learn Web Development — the canonical just-enough-web curriculum.
• Chacon & Straub — Pro Git — free, definitive; chapter 10 for what git actually stores.
• A Tour of Go — the official walk through the language, enough for project three.
• MIT — The Missing Semester of Your CS Education — the shell, editors, git, and debugging tools that courses assume and never teach.