Reading Code Like Poetry

I read a lot more code than I write. This is, I think, a confession most senior engineers should make. The myth of the engineer is the engineer at the keyboard, hands flying, eyes wide, output flowing. The reality is the engineer in their chair, scrolling, reading slowly, occasionally circling back, building a model of someone else’s thinking.

Reading code is the discipline at the center of the craft and almost nobody teaches it. There are entire degree programs in writing software. There are no degree programs in reading it.

How I read code

• Start at the entry point. Whatever boots first, read first.
• Read top-down for shape, bottom-up for surprise.
• Take notes by hand, even just three lines per file.
• Read tests before implementations. Tests tell you what the author was afraid of.
• When you find an unfamiliar pattern, stop and learn it. Don’t skip.

Reading code is the only way to find out what a program means, as opposed to what its author hoped it meant.

If you want to grow as an engineer faster than your peers, read more of their code than they do of yours. The best engineers I know are not the ones with the highest output. They are the ones with the deepest familiarity with everyone else’s output. They have, somewhere in their head, a working model of how the system actually behaves, and they got it the slow way: by reading.

Try this for a week. Read one PR a day from someone you don’t normally work with. Take three lines of notes. See how your meetings change.