this post was submitted on 21 Oct 2026
38 points (100.0% liked)

Programming

28928 readers
428 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS
 

Hello all. I work on a small team and I’ve been tasked with taking on the bulk of code review for when my senior goes on leave. Although I’ve read a fair bit of code (man am I lucky I learned to code before AI “got good”) I can’t say I’ve done a lot of actual “review”. Does anyone have any tips? I feel responsible if anything breaks after I review it so of course I want to avoid that.

you are viewing a single comment's thread
view the rest of the comments
[–] emb@lemmy.world 3 points 1 day ago

Review to understand, not necessarily to find problems. If you do find bugs and anti-patterns along the way, great, ask about them. But consider it your goal to learn what they did, why they did it this way.

When you're giving feedback, phrase things as questions most of the time. Idk about you, but I'm rarely so sure of myself. If you're saying stuff like "Would it work better if we tried xyz?" instead of "Change this to do xyz.", people respond better. Sometimes it starts a discussion, sometimes you learn they had a good reason for what they did in the first place.

It'll be really tempting to skim and just give it a quick Looks Good To Me. Try not to.