Thoughtful Code Reviews

Software engineers write a lot of code and probably spend even more time reading it, but giving and receiving code reviews is an interesting piece of our work that has a lot of implications on individuals, the team, and ultimately the quality of the user experience in what we build.

The following anecdotes come from two of my past (and hopefully future again!) managers who played pivotal roles in shaping my career. These were formative periods of growth and achievement as Hinge went from being a scrappy startup to an international and billion dollar scale-up tech business. Personally I went from an engineer who had never had exposure to production systems at significant scale to being personally responsible for one of the best dating Android apps on the planet.

The first manager approached code reviews with a deep sense of curiosity and mentorship. They took the time to read each change request carefully and left comments that invited self-reflection. Rather than simply point out syntax issues, they would ask about the decision-making process behind the changes—questions that prompted me to think about distributed systems, user experience, and high-level architectural implications.

At this point in my career I was a mid-level engineer at Hinge. This was my first experience with production systems at scale. I had a lot to learn, and I appreciated how these questions stretched my thinking and to ask these questions myself.

I've since realized he was simultaneously teaching and growing me, ensuring a level of engineering quality both then and multiplied into the future through me, and keeping a grasp on their own understanding of all the engineering efforts going on. There was a lot going on during the Hinge pivot and landing the plane of a rebuilt product while rebuilding the team is one of the most impressive orchestrations I've seen an engineering manager perform. Later when we exploded from 5 to 30 engineers we all extended what we had taken and were able to start scaling the business for the years to come.

The second manager who had an outsized impact on me did so during his onboarding period to the company. While their technical understanding was excellent, like most new leaders they didn't have the institutional knowledge established on what projects were in flight, where technical debt was, or why the changes being made were happening. Their approach was to find tickets, stories, epics, or product requirements where they could and ask questions both in and out of code review about how changes were related.

Quickly the code reviews turned into highlighting with praise when there was business value, asking how approaches were considered, adding notes for created issues.

Not only was this approach likely helpful for them to quickly understand what was going on and where to find information, but as the recipient it felt great to have my work be acknowledged and obviously understood.

When our conversations touched on this and we decided to try out bringing the principles of this approach to the team. This was definitely one of the things that helped us double the team 4 times in 4 years while maintaining high trust, cohesion, and cross-team knowledge to prevent heavy siloing.

These experiences show that code reviews are more than just a quality control measure. Done thoughtfully, they become a vehicle for teaching, learning, and fostering team collaboration:

1. Asking thoughtful questions that consider the engineering expertise not yet attained helps create that expertise.
2. Encouraging a reflection on why we're doing what we're doing and bringing attention to work that could otherwise be overlooked can create a sense of community and purpose.

A good review stretches both the reviewer and the author, encouraging deeper thinking, understanding, and growth. It’s not about catching errors—it’s about encouraging better questions, better decisions, and better relationships within the team. Automation and planning should catch errors. Reviews are about better software engineering, which is as much a social problem as a technical one.