Every article is filed under one of 312 categories. 342 pieces so far.
What the job actually is, how software gets built by teams rather than individuals, and the vocabulary the rest of the roadmap assumes.
The machine under the runtime: memory, processes, files, numbers, and text. The things that explain bugs no framework doc will.
What languages differ on, what they only appear to differ on, and how a type system changes the bugs you can still have.
The languages you are most likely to be paid to write, what each one is genuinely good at, and the trade-off it made to get there.
The structures that cover almost everything, the algorithms worth recognising on sight, and the complexity vocabulary to argue about them — plus the point where theory stops predicting the benchmark.
Git as a content-addressed object store rather than a set of memorised commands, plus the workflows built on top of it.
Writing code the next person can change: naming, decomposition, refactoring, and the review habits that keep it that way.
Structuring a system so the parts that change together live together, and the boundaries hold under a decade of requirements.
The contract between systems: HTTP semantics, the styles built on top, and the versioning problem every public API eventually has.
The browser as a runtime you do not control: how a page actually becomes pixels, and the decisions that make it fast, responsive, and maintainable.
Building interfaces that work for people using a keyboard, a screen reader, magnification, or simply a bad connection and a small screen.
Modelling data so it stays correct, and understanding the engine well enough to know why the query is slow.
What changes once a call can be slow, fail, or arrive twice — and the patterns that keep a multi-service system honest.
Assembling known parts into a system that meets a stated requirement — the method, the recurring patterns, and the numbers that decide between them.
The classic problems, worked end to end — requirements, estimates, data model, high-level design, then the deep dive an interviewer actually pushes on.
Doing several things at once without corrupting state, and making the whole thing fast by measuring rather than guessing.
Building a suite that catches real regressions, runs fast enough to run every time, and does not have to be rewritten with every refactor.
The attacks that actually happen against ordinary applications, and the defaults that stop most of them before they start.
Getting code from a laptop to production repeatably: dependencies, pipelines, containers, and release strategies that can be undone.
Running what you built: knowing it is healthy, finding out why it is not, and responding without heroics.
The parts of the job that are not code: writing, deciding, disagreeing, mentoring, and growing past your current title.