u/minimal-salt

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

we have a 15 minute standup every morning where 8 of us go around and say what we did yesterday and what were doing today and like 6 of those 8 updates are "same thing as yesterday, still working on the X feature, no blockers"

ive been keeping loose count and the last actually useful standup was probably 3 weeks ago when someone mentioned they were stuck on something api related and someone else said oh i hit that yesterday, dm me. cool. that was great. that also could have been a slack message that took 30 seconds instead of a 15 minute meeting where 6 other people sat and listened to it

i know there are theories about why standups are valuable. team cohesion, surfacing blockers, blah blah. but in practice for our team its basically a calendar tax that we all participate in because nobody wants to be the one who suggests killing it and looks like the person who hates teamwork

we've tried a bunch of variations over the last year. async standup in a slack channel where everyone posts their update by 10am (worked for like 3 weeks, then half the team stopped posting). geekbot for automated prompts (same problem, people stopped responding). a daily digest from the coderabbit agent that pulls open PRs and merges from github (useful but doesnt cover the human stuff). twice-weekly instead of daily (this one actually helped a bit). none of them stuck as the permanent thing because someone always feels like were losing the face time

i think the real issue is the daily ceremony version is mostly serving the form of the practice and not the function. the function is "surface blockers and share context." you can do that async or weekly or in a slack thread. the form is "8 people on zoom at 9:15am" and we keep defending the form because changing it feels rude

idk maybe its just me. every senior on my team has said something similar in 1:1s and then we all sit in the meeting the next day and say the same thing as yesterday

ive done node for a couple of backend projects, a small service in go, played with rust for a side thing. theyre all fine, genuinely

but every time im starting something that actually has to ship and be debuggable in 2 years when im not on the team anymore, i reach for spring boot again. ive been doing this long enough to know its not just inertia

the reason is predictability. when something breaks at 2am i know where to look. theres always a controller, always a service, always a config class, the actuator tells me whats happening, spring security has the same shape it had 5 years ago. its boring in the exact way production systems should be boring

with node you can have 4 projects at the same company that look completely different. with go you write everything yourself which is fine until you onboard someone. with rust "the right way" still changes every 18 months. spring boot has been mostly the same since 2016, the answer to most "how do i do X" questions is on stackoverflow from 2018 and still works

i know its verbose. but the verbosity is mostly metadata, its telling future-you what the code does without having to read every line

(actuator alone is worth half of why i pick it. health checks, metrics, thread dumps, standardized across every spring app, i can debug any spring service even if ive never seen it before)

i went and tried the alternatives partly to escape spring boot. trying them made me more convinced its the right answer, not less

we were running about 3 weeks behind on a release last month so management's solution was to move 3 more devs onto the project. i tried to say my piece in the meeting about how this was probably going to make things worse before it made things better, got the polite nod, and we moved on

now we're 5 weeks behind. and not because the new people are bad, theyre fine. its because the original 4 of us are spending probably half our time answering questions, walking through how the auth system works, explaining why we made a weird choice 8 months ago that now looks dumb but had a real reason at the time, reviewing PRs that need 3 rounds because the new folks dont have the codebase context yet. all of which is the right thing to do, but its also the thing that wasnt happening when we were just heads-down shipping

it always remind me the book brooks wrote the mythical man-month in 1975. fifty years ago. "adding manpower to a late software project makes it later" is one of the most-quoted sentences in software management, every PM has either read it or heard about it(idk about nowadays..). and managers still do this exact thing constantly. i think because the alternative (telling the business "we're going to be late and theres nothing we can do") feels worse politically than doing the wrong thing that at least looks like you tried

and to be fair, sometimes adding people is the right call, if the project is going to take 6 more months, you absolutely want more people on it now even if the first 2 months are a wash. but for a project that's 3 weeks behind on a 4 month timeline, the math just doesnt work. by the time the new folks are net positive contributors, the deadline is already past

i think the deeper thing is communication overhead scales worse than people expect. 4 devs is 6 communication channels. 7 devs is 21. its not a linear cost, every new person added makes coordination harder for everyone who was already there

next time im in a meeting like this i should probably print out a copy of brooks and slide it across the table. probably wont work. nothing else has