not exactly reviewing them. theyre already merged, already shipped, the review happened. i just read through everything that landed in the codebase the day before. takes maybe 15 minutes with coffee before i open anything else

i started doing this maybe a year ago after i got blindsided in a planning meeting by a change i had no idea went in. someone had refactored how we handle a chunk of our auth flow and i was sitting there talking about building on top of the old version like an idiot. so now i just stay aware. not deep, just aware

most mornings its nothing. boring dependency bumps, copy changes, a test someone finally fixed. but every couple weeks you catch something. last month i noticed two different people were independently building basically the same caching helper in two services, neither knew about the other, and i only caught it because both PRs merged the same week and i happened to read both. flagged it, they talked, one of them deleted their version. fifteen minutes of skimming saved a month of two slightly different cache implementations drifting apart

the thing nobody tells you about going senior is how much of the job becomes just knowing whats happening. not doing it, knowing it. you cant make good calls about where something should go if you dont have a rough map of where everything already is, and that map decays fast on a team thats shipping every day

it doesnt scale infinitely, i'll say that. back when we were merging 40+ a day i couldnt keep up by hand and mostly relied on whatever surfaced. we've got the usual pile of stuff running, claude code, codex, cursor, a coderabbit agent that posts merges and open PRs into slack, internal scripts. and checking the why is the part thats actually worth the 15 minutes. so the manual skim is still the thing at our current pace

anyway thats it. the tooling will tell you what changed. reading the diffs yourself is still the only way i know to understand why, and the why is what you actually need when youre deciding where the next thing goes