Code Reviews For Deeper Knowledge

Participating & Collaborating With Intention

Written by Frédéric Caplette

As a recently self-taught programmer, I can say that I find learning to code something functional relatively easy. Get an error after running your code? Google it and find one of hundreds of posts with the answer you are looking for, already prepared for your copy-pasting pleasure. But learning how to make an efficient, performant, well thought-out future proof program that respects the coding language idioms? That’s an entirely different story and it’s why I started asking myself a simple question: how can I validate what I learn?

One of the solutions that we are applying at e180 is the classic code review. For those of you who don’t know, a code review is a regular meeting between developers — in our case, once a week — where a team member has to present a section of code created in the past month and explain not only the functionality, but also the reasoning behind it. This ensures that other people, with different experiences or preferences in programming, will see and evaluate the code in their own terms. When questions arise from the explanations, we simply ask the developer on the spot. If the answer is not clear or if it is deemed that there could have been a better method, then the programmer can discuss with the group, learn from it and perfect the code. In this context, the person presenting is receiving valuable feedback on the methods s/he is using while those listening can think about how they would have tackled the issue themselves and compare that to the solution presented. It’s a learning strategy that benefits everyone attending the code review.

Here is where it gets interesting though. Can we say that improving the code is the goal of the code review? It’s certainly important, but if that’s all there was, I would honestly find it a bit underwhelming; there are dozens of other ways to improve your code that are just as valid. No, the real value from collaborative learning — which is what we are doing here — is the fact that the method is being evaluated and you are doing so by co-creating knowledge together.

The real value from this collaborative learning is the fact that the method is being evaluated and we are doing so by co-creating knowledge together.

To stay in the code review example, I can say without any shame that I am the least experienced programmer we have at e180. I have very little technical knowledge (new to them) that I can share with my coworkers, which could lead us to believe that when it’s my turn to present, I will be the only one to benefit from the review. And yet, because my reasoning is different, the way I solve problems might be as well. My seniors have to think about how they would solve the problems I faced and justify their opinion on the matter, which in turn also reinforces their own understanding. On the other hand, when a more experienced programmer is presenting, I will take the role of observer and really focus on understanding the reasoning behind the code, asking questions when there are things I don’t understand. The magic of the code review is that no matter your level, if everyone participates with the intention of learning, then everyone will get something out of it.

The magic of the code review is that no matter your level, if everyone participates with the intention of learning, then everyone will get something out of it.

Learning more about the method allows you to gain valuable knowledge that not only applies to one specific question, but to past and future issues as well. This brings us to talk about the different type of knowledge. You will always be exposed to what I call ‘Binary Knowledge’ and ‘Deep Knowledge.’ Binary Knowledge is something that you either know or don’t; there is no middle ground. It’s knowledge in predetermined fashion, something that does not give any additional value in its respective field while Deep Knowledge is something that will make you truly understand a topic more broadly. To make it clearer, let’s use cooking as an example.

If I know a recipe by heart, let’s say a very good one that can be rated on the level of a meal at a high-end restaurant. I cook it once a week, know all about it by heart, and always use the exact same ingredients, in the same order. But I can’t cook anything else, not even a simple bowl of pasta. Does that make me an expert in Cooking? Not at all. This is a manifestation of those two types of knowledge. The recipe is binary because I don’t understand it. I follow steps that I know are the good steps, but I don’t know why the cook uses paprika and not chili flakes. I won’t be able to use this knowledge in any other cooking experience because I don’t understand why each ingredient is used.

If we go back to the code review, when a programmer presents the code that was developed, and the only learning that comes from it is that “X should be done like this” then that knowledge will be applied to that part of the code, but it will not be reused spontaneously later down the line of development. To ensure that what you are learning is deep knowledge, then you must ask yourself this type of questions:

• Can I now solve my problem with the answer I found?
• When could I use this solution in the future?
• When could I not use this solution in the future?
• Why is this the best solution for my problem specifically?
• Can I name other solutions that are not as effective as the one I decided to use? If so, why?

By asking yourself these questions and making sure that you can answer all of them, you will know that you are not simply accepting something as knowledge when, really, it’s just a shortcut. All binary knowledge can be turned into deep knowledge, if you take the time. One of the easiest ways for me to do so is by asking myself these questions or by having other people around me asking or answering some of them in the context of a conversation. There is a limit to the number of solutions you can imagine by yourself, having more people challenge your decisions, expose alternative and creative ways of solving your problems will expand the bank of answers that you can give to your questions.

As is the case with many creative endeavours, when seeking feedback or facing criticism it’s essential to keep an open mind, to see comments or questions as learning opportunities, not as failures. Whether you are accepting suggestions, framing a rebuttal or defending choices, you can always see this process in a positive light and benefit from it.

e180 is a social business from Montreal that seeks to unlock human greatness by helping people learn from each other. We are the inventors of braindates — intentional knowledge sharing conversations between people, face-to-face. Since 2011, e180 has helped thousands of humans in harnessing the potential of the people around them, and we won’t stop until we reach millions.