Reading code is the job
2026-06-11 · Engineering · 1 min read · @TechScribeWire
Ask a junior engineer what the job is and they will say “writing code.” Ask a senior one and they will laugh, because they know the truth: you spend far more time reading code than writing it.
Why reading is hard
Writing is generative — you are externalizing a model you already hold. Reading is the reverse: reconstructing someone else’s model from the artifact they left behind, often with no comments and a commit message that just says “fix”.
A method that works
- Start at the edges. Find where the code talks to the outside world — an HTTP handler, a CLI entrypoint, a queue consumer — and trace inward.
- Follow the data, not the control flow. Where does this value come from, and where does it go? Data flow reveals intent faster than stepping line by line.
- Run it. A debugger and a single breakpoint will teach you more in five minutes than an hour of static reading.
Read for the why
The code tells you what it does. Git blame, linked issues, and tests tell you why. When you understand the why, the strange-looking branch usually turns out to be load-bearing.
Get good at reading and everything else compounds: reviews get sharper, debugging gets faster, and you stop rewriting things that were fine.