We do them to improve ourselves

Short piece on an interesting discussion at a customer yesterday: we are testing what I call “AA” (as in Alcoholics Anonymous meetings) code reviews meetings with the team. Those are for developers only (no non-developer is present), and anyone can bring a piece of code he wrote:

“Hi, I’m Martin, and I wrote this shitty code”.

The group then discuss the piece, proposing improvements, challenging design and implementation choices (so the “AA” name).

At the end of a one hour session with five people, we did a quick round table to collect feedback (this type of code review is pretty new to me too). One of the developer pointed out:

“We just spend one hour with five people on this code, and while the discussion was good, the improvements we proposed will not change that much. That is five man-hours for very little, as the point is to improve the code.”

First of all, this reaction is stellar, as it putS the focus on the good point: we’re using time that could be used to fix bugs or deliver features to our customer. Challenging whether this time is well spent is both wise and necessary.

Second, it made me realize we had missed an opportunity to set up our common goals for those AA sessions, as I actually agree: five man hours for this improvement is too much, and improving the code could have been done in a much more efficient way (with a single peer review, for instance). But that was not my goal for this meeting.

We don’t do code review to improve the code. We do code review to improve ourselves. This is why it’s like the AA: were not there to compare who is writing the shitiest code – we try to help each other, and initiate a virtuous circle. We do that between ourselves, recognizing that everyone can and need to improve.

Those meetings are a way to say: “quality is important to us, and it may not be top notch right now, so we recognize the problem and want to improve, and this is a job that involves everyone every day”.

The improvement of the future code is a by product having improved developers.

I did learn quite a bit during that session, which by that measurement was a clear success, so I’m looking forward to our next SCA meeting.