01Learn to Read Before You Learn to Write More
Every junior developer wants to write more code. The seniors they admire spent most of this week reading it.
Reading other people's code — unfamiliar codebases, open-source libraries, colleagues' pull requests — is the highest-leverage learning habit available to a working developer, and almost no one teaches it deliberately. Courses hand you blank files. Bootcamps reward output. Meanwhile, the skill that actually separates a developer who compounds from one who plateaus is the ability to walk into an unknown codebase and make sense of it fast.
Start with the entry point, not the README. The README tells you what someone wanted the project to be; the entry point tells you what it actually does. Find main.js, index.ts, app.tsx — wherever execution begins — and trace forward. Resist the urge to understand everything at once. Follow one path through the code as if you're the runtime: what gets called, what it returns, what side effects it causes. The rest of the codebase will reveal itself in concentric rings once that first thread makes sense.
When you hit something unfamiliar, fight the instinct to tab out and Google it immediately. Sit with it. Read the surrounding lines. Often the usage context tells you more than MDN will in the first thirty seconds. That tolerance for confusion is itself a skill, and it builds with practice.
Pay attention to what the code doesn't do. Experienced developers leave decisions in the negative space — a missing abstraction is often intentional, a simple loop preferred over a clever recursive function for a reason. Ask yourself why the author made this choice rather than the obvious alternative. You won't always find the answer, but the question sharpens how you read and, eventually, how you write.
Pull requests are the best classroom most developers ignore. Reading a PR isn't just about catching bugs — it's about watching another developer's reasoning unfold in diff form. The description, the approach, the edge cases they handled (and the ones they didn't) — all of it is a real problem solved in real conditions, which no tutorial replicates.
Pick one well-maintained open-source project in your stack and read a little of it each week. Not to understand all of it — that's the wrong goal. To get comfortable with unfamiliarity, to collect patterns, to internalize idioms you'd never have invented yourself.