Spaghetti Code, Red Faces, and PR Wisdom: My Journey to Becoming a Better Reviewer

Opening (Setting the Scene)

I remember the first time I reviewed a pull request for an older colleague at one of my previous jobs. Let’s just say it didn’t go quite as I had imagined. There I was, eager to level up, step into a more senior position, and share all the best practices and principles I’d accumulated along the way. I was typing away at my keyboard, trying to be helpful, but something about that PR... something about my comments... well, let’s just say I’d never seen someone turn that shade of red before. On the bright side, it was a great learning experience.

---

The PR Review Incident (The Trigger)

Looking back, I can now see how my “constructive feedback” might have come off as a bit... let’s just say it wasn’t as constructive as I thought. At the time, I was leading a small pod of three to implement a feature for the company’s portal. I was responsible for understanding and questioning the scope, organizing and breaking down tasks, and also contributing to the feature itself.

At one point during the cycle, I reviewed a PR where I made over 100 suggestions. From minor pattern inconsistencies and readability issues to some programming principle changes I felt needed to happen. But apparently, what I actually said was: "This looks like a spaghetti monster was unleashed on your code." Yeah... not exactly the kind of rapport you want to build with someone who’s been coding longer than I’ve been alive. And, yeah, I definitely saw that passive-aggressive eye twitch.

---

The Moment of Realization (Reflection)

It took a couple of awkward, silence-filled meetings and a one-on-one with the head of engineering to realize that, just maybe, I wasn’t being as diplomatic as I thought. I wasn’t just reviewing the code; I was reviewing the person behind the code. And let’s face it, no one likes hearing that their baby looks like it was drawn by a toddler, even if that toddler is technically you.

This realization hit me hard. I knew I was right and felt like I was doing the team a favor, but I admit it, I was wrong. I could’ve done the same thing, but with a little more finesse.

---

The Shift in Approach (Action Taken)

After that incident, I decided to take a hard look at my approach. I figured if I could learn from it, not only would I avoid future awkward moments, but I’d also become a better colleague (and person, for that matter). So, I made a few key changes in how I reviewed PRs:

• Change the subject of my review comments: Instead of using something like "You should...", I started using "We should...". This shifts the tone from pointing out mistakes to framing it as a team effort. If one of us makes a mistake, it’s like all of us have made it. If one of us improves something, we all get credit.
• Start with a compliment. Seriously. If I can’t find anything good to say, I'm probably the one who needs to be reviewed. There’s good in the bad and bad in the good (Yin and Yang, right?). Praise what deserves praising.
• Ask questions, not demands. Instead of saying things like "This needs to change" or "You should do this", I started involving the author in the review process, asking "What do you think about doing it like this?" It turns out, people like having ownership of their own code. Plus I found that this approach builds confidence in others encouraging them to develop their own opinions and sometimes learn a lot from the answers I got. If you think you know it all, well... you're probably not as smart as you think.
• Be specific. Use examples. Instead of vague feedback like, "This approach is wrong", I started explaining why I was suggesting changes. I’d say things like, "This logic might cause issues if..." and, most of the time, I’d follow it with a link to an article or documentation that backed my suggestion. Not everyone wants to follow blind instructions without understanding why. Plus, this approach fosters a team culture of reading and sharing knowledge.
• Tone is everything. I started putting myself in the author’s shoes. If I received the same feedback, would I appreciate it, or would I want to crawl into a hole and never write code again? If it didn’t sound kind or constructive, I’d reword it.
• PRs are collaborative, not combative. It’s about improving together, not trying to show off or prove that you’re the smartest person in the room. Keep calm, be kind, and influence for the better.

---

The Result (Progress Made)

Fast forward a few months, and my PR reviews have gotten much smoother, far fewer awkward silences. I’m talking clear, friendly communication, questions that actually get answered, and way fewer facepalm 🤦‍♂️ moments. More collaboration, more back-and-forth on ideas and approaches, and, honestly, I’ve learned a lot more too. I’ve also noticed a positive shift in the team culture. It was almost like a miracle had happened. In the end, I realized I had grown as both a reviewer and a collaborator.

---

Closing Thoughts (Wrap-Up)

So, yeah. I’m not saying I’m perfect now (because, well, who is?), but my PR reviews have definitely gotten smoother since that fateful encounter. I guess the moral of the story is: don’t be the person who gives feedback like they’re throwing stones from a glass house. And always remember: when reviewing PRs, it’s not just about the code; it’s about the person behind it. It’s about growing together as a team and helping each other become better versions of ourselves. If you grow, I grow. We all win.

---

In the end, I also learned something pretty profound: Before reviewing a PR, have a pint of cold beer 🍺. A beer brings out your good side (well, most of the time).

Until the next brain fart, stay safe, don’t chase, and bye for now.

The End