I started out as a junior developer, getting a dozen (or more) comments during every code review. Later, as a mid-level dev, I felt almost obligate...
For further actions, you may consider blocking this person and/or reporting abuse
Totally agree with you,@sylwia-lask .
However, after reviewing and commenting on around 4–7 PRs, developers often start to recognize the recurring patterns and areas of improvement highlighted by the reviewer. This not only reflects the reviewer’s guidance but also demonstrates the submitter’s ability to learn, adapt, and apply feedback effectively.
Totally agree — you can definitely see those patterns forming after a few reviews.
It’s always great to watch how people start catching and fixing those things themselves over time. 😊
I'd much rather work in an ensemble or pair than do PR code reviews. The problem is that PR reviews make it harder for the reviewer to gain context.
I think it depends on your knowledge. Even as a senior working on something you haven't done before you call in help from someone who has experience to check your work. That can be face to face or with a PR.
I think the more knowledge you have less the need to partner up. The more I also feel that I accomplished something.
I have the same feeling doing things around the house. It is nice to know when you can rely on someone who knows what needs to be done. Instead of seeing a few youtube videos and go in head first.
Of course with a PR you don't just tag someone as a reviewer without giving some context. Add a link to the issue, add instructions how to test the changes.
Totally agree — experience doesn’t mean doing everything alone, it means knowing when to ask for help and how to collaborate effectively.
Love the house analogy too 😄 And yes, adding context to a PR is such an underrated skill!
I get that! Pairing gives you instant context and better flow.
I still think PRs can be valuable — but only when reviewers are already involved in the work early on. Reviews without context can feel like reading a mystery novel from chapter 7 😅
A phrase I use when I do have a bone to pick but don't want to fully go to the mat over something is to say, "approved, but I think next time..."
It keeps the smaller nitpicks from distracting from the bigger stuff and keeps devs from feeling too called-out when there are several things in the review. I've found most of the time folks will just go ahead and fix it in this version as well.
Honestly, if it's a really bad PR and I know I'm going to want to leave several comments, sometimes I kill my darlings and pick a couple things to say, "approved, but I think next time..." about even if I feel strongly about all of it. It's just too expensive in terms of social capital to bleed red all over someone's work.
That’s such a great way to put it — “approved, but I think next time…” has exactly the right tone.
I used to be the person who would leave 20+ comments and wait until every single one was addressed before approving 😅
Now I’m also team “approved with suggestions.” Makes everything smoother for everyone.
💯
Totally agree ; focusing on key feedback makes PRs smoother and helps juniors learn faster.
Hey Sylwia 👋
Thanks a lot for checking out my recent post about BusinessAdBooster 🚀
Really appreciate your support! Also loved your insights in this article — super relatable! 🙌