Code Review Challenges

I had a similar problem with an architect on my team. I realized that the architect was spread too thin, so by the time they came back to discuss or look at something again, they would not have time to remember what they had recommended previously. I went through a few cycles where I would implement a change they asked for, and then they would ask me to change it again in a slightly different way, because they forgot what they recommended previously.

While this code is the most important thing happening for you, it is only one of a thousand tasks that are competing for space in the tech lead's brain. I would recommend a 1-on-1 and fill it with questions, not statements. That's what I did when I encountered something similar, and it was incredibly helpful. I was able to get a grasp on the larger goals the person was targeting for the code, so I could write code in line with their larger goals.

You can also walk through the code during the 1-on-1, so you can get more details on why they are asking for what they're asking. The fastest way to remove the review comment back and forth is to have the conversation over a call or in person.

First, I highly recommend reviewing this session we gave about 2 years ago now: [Masterclass] How To Do Amazing Code Review.

Eventually, you are right to reduce the number of "roundtrips" that happen on code review. Ideally, you're able to put out a code change and then have it approved on the first pass, perhaps with a few comments that the reviewer will trust you to address before merging.

However, as an intern, you should not expect this level of speed. As someone more junior, and new to the codebase, you need to earn trust and ramp up on the codebase patterns.

I have a few thoughts on your situation:

• Sometimes the best way to ask a question is to make a draft code change -- "code speaks louder than words."
  • Once you have the change, then walk over to the TL's desk, or show them the draft PR and ask for feedback on parts that you're confused about. Then publish it when it's in a reasonable state and you feel you've answered all the basic questions.
• It's totally fine for you to have lots of back and forth initially on code review, especially as an intern. I wouldn't blame yourself or the Tech Lead in this situation. Sometimes the TL needs to see the code in context to remember edge cases or logging requirements.
  • The more important thing is that you don't get identical feedback twice. Now you know that race condition alerts should get logged: make it a point to do that in future PRs, or acknowledge that you checked for race condition PRs in the test plan.

It's worth meeting your TL, but I wouldn't frame it as an "issue." Instead, ask questions that show your willingness to learn and be curious:

I noticed your comment about adding logging for race conditions. How would you recommend I identify that kind of issue on my own?

Are there other examples in the codebase you could point me to?