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:

# bad
a = -> (x, y) { x + y }

# good
a = ->(x, y) { x + y }

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

Running the linter would have saved me from most of those 40 comments. The company had a style guide, after all. But the rest of the feedback was a different kind entirely. It was about which design patterns the team had quietly agreed on without documentation, or what parts of the codebase were more coupled and fragile than others. That knowledge belonged to one person, and they knew it. Call them the sole proprietor of the codebase. What happens to everyone else’s code when that person is out sick? 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 sole proprietor merges their own code freely, everyone else has to rely on their knowledge and expertise to get their code sufficiently reviewed.

While there are 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 best. This showed me the more obscure parts of the system.
2. Have them re-review my code on a call for under 30 minutes, after a first round of asynchronous reviews. This means I’ve already seen the kind of feedback or concerns they have, and can go in with more in-depth questions or follow-ups.

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 throwing together a decision log or an automated linter, if there aren’t any, 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. I won’t pretend pairing feels like the most efficient move. It’s slow, and sometimes more than a little humbling. But ultimately, it’s the only thing that worked to earn trust from everyone on the team.