Reader Story: Impact of Code Review

Created: October 29, 2020

Reader Anon E Moos is back with this story about the impact code review has had on their practice (shared with permission, anonymous by request):

So new subject code reviews, its kind of related right 😉 . I remember way back when we first implemented them just how annoyed the team got as peers provided feedback, asking for style corrections changes of logic.

That feeling when you are short on time on a development sprint and think you have squared away an issue only for it to re appear on your to do list ! The process helped us adopt a standard style, and lent itself to adopting a much stricter enum structure. The biggest change came as we started migration from ss1.0 to ss2.x simply because a refactor of code to promote a function to a library became much easier.

Code reviews are now a personal challenge for me; we have a guy on the team who is meticulous and precise (and I love him for that) and I get a sense of satisfaction if the code is approved first time, or better still a positive comment to go with it.
This story is great as it exemplifies the fly-wheel effect that right-sized processes have on an individual and a team.

I hold no illusion that new processes don't come with their share of friction and pain. That's a totally normal part of team formation - the Storming phase. Any time you modify a team's structure or its processes, they'll go through these five stages of change.

In fact, one of the more disruptive actions you can take is adding more people to the team. This generally causes the longest Storming phase unless you have an excellent onboarding program. If your team's objection to process is still "We move too fast for process!" and then in the next breath you say, "But we're hiring like crazy!", perhaps it's time for a closer examination.

If your team is moving too fast for process - whether you're in charge or not - I'd love to speak with you.