The PERFECT Code Review: How to Reduce Cognitive Load While Improving Quality
Posted by fagnerbrack@reddit | programming | View on Reddit | 12 comments
Posted by fagnerbrack@reddit | programming | View on Reddit | 12 comments
buildingstuff_daily@reddit
cognitive load in code reviews is the thing nobody talks about but its the reason most code reviews are useless. the reviewer is mentally exhausted by line 50 and just starts approving everything after that
the best code reviews ive been part of had a strict "one concept per PR" rule. if your PR does two unrelated things, split it. yes it means more PRs but each one gets actually reviewed instead of getting a rubber stamp because the reviewer doesnt have the mental energy to understand a 500 line diff
the other thing that dramatically improved our review quality was having the PR author write a 2-3 sentence summary of WHY the change was made, not what changed. the diff shows me what changed. what i need to evaluate is whether the approach makes sense for the goal, and i cant do that without understanding the goal
darkpaladin@reddit
One area I actually like AI for is not "do this pr for me" but "can you give me a high level summary of what this diff is trying to accomplish and make note of the entry points and control flow." Then I've got something of a roadmap for when I'm going through it myself so I don't need to try and keep everything in my mental model.
Part of what drains me do much on GitHub reviews is they're laid out in project structure order so you have to jump around and track the control flow yourself. Having a map of what order to look at the files without having to think about it too hard helps tremendously.
mjbmitch@reddit
AI slop
BertDevV@reddit
Not every comment or post with paragraphs is AI. Some people can actually think and write themselves.
mjbmitch@reddit
The paragraphs didn’t clue me in. They used phrases people outside of influencers never actually use “people never talk about”
They’re engagement farming and using AI to write their posts
buildingstuff_daily@reddit
i wish i was AI. unfortunately i'm just some dude who spent way too long thinking about code reviews when i should've been touching grass lmao. but hey at least i didn't spend my evening typing 'AI slop' on strangers posts
anengineerandacat@reddit
All valid, we have pretty strict adherence to PRs being for the story only and we try to keep stories down to small actionable and demo-able units of work. No fixing a defect in the middle of your implementation for your story.
For the PR itself, needs links to the story, summary of the changes (so we can gauge if you even knew what your changes were supposed to do), and details on how to test the code / get to where your changes had impact.
Ie. If it's backend it has a cURL attached and a sample response, frontend a link and screenshot, etc.
No booger flicked PRs I ain't your QA, I am a peer reviewing your work so your not the only one accountable.
No-Childhood-2502@reddit
this is a growing problem as we go forward, build agentdiff for the same now know per line written by agent as what prompt drove it, what wa the inent behind.
https://github.com/codeprakhar25/agentdiff
Mrblahblah200@reddit
Another ACRONYM that will solve nothing and will be picked up by overenthusiastic managers
MRxShoody123@reddit
20% to 30%, how do i justify this
Rulmeq@reddit
I'm a bit dumb, was trying to figure out how to pronounce TCEFREP
Shred_Kid@reddit
Yeah so evidence needs to be significantly more important here idk
Maybe I just have too many juniors on my team