Everybody knows Pokemon Go! Many loves it! Why? Because there’s something to hunt for.
That inspires me to apply the concept to Peer Code Review. How?
The idea is simple. Before submitting your code for review, why don’t you intentionally left some Pokemon to be hunt. What do I mean? I mean explicitly put in some non ideal codes when you submit your code for review, let others know they are there, so that they have something to catch.
How is Pokemon Go Peer Code Review better?
It’s much more fun, as there’s definitely something to hunt for.
I know professionally, everybody should do their best. Write the best code, and perform the best review to catch noncompliance, issues or even bugs. That’s the ideal world.
But we live in a non ideal world… at times fatigue came into play. Reviewing other people’s code is not always fun. A quick scan through to see if there’s anything obvious, else just LGTM. Worst still, when a junior developer to review a senior developer’s code, some junior would assume whatever senior developer wrote, it’s the ‘golden rule’.
It would be so much different if the reviewer know there’s at least one if not more Pokemon in the code, not only it is exciting and fun to hunt for it… it will trigger more thoughts when one is hunting it, and I believe could catch some real Pokemon that really creep into the code!
It removes “hall of shame” feeling when Pokemon are detected
I remember one of my math teacher, when he was caught working the equation incorrectly while working on in on the black-board (ya… old old days when chalks are still being used) by the student… he would grinning say, “I purposely do so, to see if you are paying attention to what I did”.
In Pokemon Go Peer Code Review, when some Pokemon are caught, the coder have the choice of admitting it’s a genuine miss, or could “bluff” away stating that was intentional. Either way, that’s not important, as the code could be improved. The intention of Peer Code Review has never been to “shame” people, but to improve code quality and mutual learning from each other.
It enables explicit educational learning from what’s Not Good
There are always two ways of learning. One is to look at the good example, while the other is learning from the not as good one so we could avoid it. Arguably, learning from the bad experiences would stick longer.
In our context on this point, this is especially applicable when a senior developer is letting a junior developer review his code. What a senior developer could do is focus on a particular coding convention he would like the junior developer learn, and explicitly code it against the convention, then let the junior review the code.
The junior developer while trying to ‘catch’ it, would definitely triggers much more exploratory thoughts, which is much better than the ‘spoon-feed’ learning approach. If he fails to catch it, the senior developer could then expose where the Pokemon is. This is where the learning could be really sticky. At times, perhaps the junior have something for the senior to learn as well. :)
There are some overhead of doing Pokemon Go Peer Code Review, as one would need to put some extra thought of explicitly inserting Pokemon and remember to remove the Pokemon later. But think of the extra FUN and LEARNING and the elimination of SHAME, wouldn’t this make developers life so much better?
Let’s go catch Pokemon in the code!!
Try it out and let me know how it goes. If you like the idea, do click LOVE below to share. Cheers!