Spending days, even weeks, on rounds of code reviews on every single pull request is a huge slog, and a risk. In the time that you spend revising the PR, you could end up dealing with changing requirements with new information from customers or related issues and bugs. I've even had to start all over again! This happens more often when joining a new team, while learning a new, unfamiliar codebase.

Two or three years into my career as a developer, I joined a company of more than two thousand employees for the first time ever. Before that, I'd worked at a small agency and a startup. My first pull request got 20 comments from a senior engineer on the team. When I pushed changes to address them, I'd gotten 10+ more. By the time I actually merged the changes, there were a total of 40+ comments. When I looked back a few weeks later, I winced at how much of it was avoidable. I wasn't implementing the company's style guide at all, and mostly because I hadn't even run the linter. This is an example from the style guide doc that the senior engineer had to point out in a comment:

Install and run the linter, already! - What I'd tell myself

It's one thing to miss running a linter locally - it's another to find yourself working with an engineer on the team that acts as the sole proprietor of the codebase. What happens if that person gets sick? Does anyone's code ship while they're out? I've seen this untenable situation happen in the beginnings of a new hiring round, for example, when not many people on the team have enough familiarity to be reviewers as well. While the proprietor/maintainer merges their own code freely, everyone else has to rely on their knowledge and expertise to get their code sufficiently reviewed.

While there's a number of things another (re: new) engineer can do in this situation, the most valuable thing I've tried before (however reluctantly) is to pair program. This did two things for me: establish more trust with the person with the most context, and gain enough of my own domain and codebase knowledge to be a better reviewer.

It's easy for pairing sessions to run too long and meander. These formats and goals helped me manage my own energy levels, as well as theirs:

1. Watch and observe the person tackle a difficult bug or add a use case on top of an existing, ideally mature feature set. 1 to 2 hour sessions are ideal. This showed me the more obscure parts of the system.
2. Have them re-review my code on the call for under an hour, after a first round of reviews. This means I've already seen the kind of feedback or concerns they have, and can go in with more in-depth questions.

If they avoid having more calls with you for whatever reason (i.e. too many meetings that day; got an urgent task of their own) - ask them to write up a separate ticket if their request for changes would increase the scope beyond initial requirements. Even setting a style guide document or linter together, if there isn't one, can save everyone some time.

I found that these short-term strategies ultimately don't beat paired programming as a way to demonstrate that I'm willing to learn, and to get first-hand observations of an unfamiliar, complex codebase. It's a higher time investment in the beginning that paid me back the most to become a reliable teammate myself.

​