Member-only story

The case for an “Editor in Chief” in software development teams

Pierre-Marie Poitevin
2 min readJul 17, 2020

--

I have been in many teams and companies in my career, and reviewing code was never highly rewarded in my experience. In my very first team, a teammate used to review my changes quickly and in a very consistent manner (I mean, the reviews didn’t contradict each other from month to month due to a change of style preference).

This coworker ended up leaving the team, and I don’t think at the time anyone recognized the reviews as one of the gaps that they would leave behind.

In the teams I worked afterwards, I never found someone that would review my changes in the same quick and consistent manner. Some people would approve my changes fast. but without consistently checking quality. So, when I was lazy some days, I would only want a quick approval, I was able to merge new code that would not have met my own standards. Other reviewers were whether slow or inconsistent in the questions they would ask, and I put myself in the “slow and inconsistent” reviewers category. I think my reviews were slow because it was not my first priority, and when I tried to apply some standards, other reviewers were happy to give their approval, so that in effect my comments and requests were optional.

I don’t blame anyone for being a bad reviewer, as I said, I don’t see myself as a good one. I believe that most engineer are more passionate about writing code than reviewing and enforcing standards, and in particular they don’t see much reward in the “review” part of their job.

--

--

Pierre-Marie Poitevin
Pierre-Marie Poitevin

No responses yet