Inspired by “If On a Winter’s Night a Traveler”
If you want to be less wrong, first you need a feedback loop.
Unlike most books, a pull request has two perspectives, if not more. So a brain trust of sorts. One is the person who is reviewing the PR, another is the person who submitted the PR. A sort of civilizing process via code review.
As the writer, the reader becomes your second order thinking, much in the way there is a first order and second order of thinking when doing pair programming.
Wait no. Before entering the feedback loop, you first need to forget the idea that you are right. Which is radical because we know how to do certain things in order to make the day work for us. At least have a selectively open mind. You probably should be in a comfortable place in case you forget how to do something basic – the collateral damange will be minimized.
And a code review is a great place for a feedback loop. If we’re optmizing for learning, the best thing we could probably do is make sure that PRs are addressed immediately (ping) and that the feedback is addressed immediately thereafter (pong).
Soemwhere in there is a conversation, and this is where a degree of learning takes place. The reviewer can learn something (Yes! It has been advised that instead of seeing PRs as a chore, approaching with the idea that you are going to learn something new can increase engagement). One thing I’ve found myself doing, and this is a joy of working via type instead of spoken language when reviewing stuff, is the moment where I realize I have the capability to look up something myself instead of asking the submitter a question. This is very valuable if I’m going to get something out of code reviewing beyond the superficial aspect of beng a gatekeeper.
As far as the reviewee is concerned, their learning begins when they get feedback. Let’s assume that some of it is good and immediately applicable. By recognizing a mistake / area of improvement, having it sent to them, and then applying the changes, the reviewee is more likely to retain the information. Writing it down is good too.
A reviewer can throw a stretch goal at someone which, I understand, can be frustrating for someone who feels like they are ready to ship. But maybe pushing someone a bit farther when you can sense they are operating in a comfort zone is worth instigating.
Whatever challenges you want to give the reviewee depends on how you want to shape the tone of the team. I don’t think I met anyone who has written code that can’t use some adjustment, and we don’t really have a long refinement process to lean on. So that generally means that our code is in some type of raw format when it comes down to our code reviewer.
This is also an opportunity for a senior person to guide the reviewee along their career path. A good system will have plenty of functionality to facilitate conversation about code structure, patterns, and even architecture (though I think if you are discussing architecture for the present implementation in a pull request, that’s something worth investigating).
Keep in mind, we don’t really function in a student / teacher relationship. Programming on a team is far less hierarchacal, and the idea is that anyone could have learned something over the weekend which is applicable to someone on the weekdays, for example.
So that, to me is a pretty extensive way to squeeze a pull request for all it is worth.
Once you’re done… recover??