When I joined Closelink, there was not really a process in regards of code review. Code was written and sometimes reviewed by another developer by taking a rough look at it. To be fair, as a dev team with two developers, it does not make too much sense to invest lots of time into a proper process.
At my former team at FREE NOW, we used to discuss many, many (probably too many) things in code reviews. I was so used to proper code reviews that I instantly missed them. Now being a team of four developers (three full time, one working student) I knew it was not the time to introduce a complicated process with pull requests. We needed to get stuff done, quickly. I did not want to slow down the process, I was hired to accelerate our team.
Entering Dev Critiques
Design Critiques are a common practice for design teams. They are sort of similar to code reviews but without a red/green diff. A designer presents their work, others give feedback and come up with ideas on how to improve. In the end, your team comes up with a better solution and the presenter learns from it. Win!
If something like this works for design teams, why should it not work for dev teams as well? So, we scheduled a meeting happening every Friday. Every Friday, another developer presents a topic of their choice. Preferably, a topic they recently worked on but it can be anything. It could be a topic they wish to raise awareness on, e.g. how to write better tests. Or a topic to share knowledge; Tobi (our CTO & Co-Founder) once gave us an overview about our AWS infrastructure.
With dev critiques, others can learn about the thought process behind a certain implementation. Instead of pointing out minor details (“Please add a semicolon!”), it is more a conversation in which everyone can learn something. Often, helpful discussions come up and the author might re-think their solution. Sometimes, when the presenter explains their code to others, they notice an improvement themselves.
Usually the presenter just shares their screen and explains how the code (or something else) works. People may interrupt and ask questions right away or ask the presenter to go into detail. Interesting conversations are bound to take place!
In general, it helped us creating a culture in which we talk about code. A culture in which everyone wants to improve, and where feedback is considered not a fault but a valuable chance.
Learnings
As always, there were a few learnings since we started.
Maintaining a document with upcoming sessions along with their presenters and topics has proven to be very useful. We use Confluence, but every shared note works. Just have a regular meeting in your calendar and use the document to check who is presenting when.
Try to not skip it. Often formats like these get skipped because people are on vacation or people feel like they do not have something worth sharing. We have been doing dev critiques since November 2019 and have skipped them only twice. If people are on vacation, just let someone else present.
Things do not need to be super exciting to be presented. Maybe you have something to share which you are specialised in and want the team to learn more about. Or you talk about a minor bug fix, how you were able to reproduce and fix it. I am sure it will start a conversation! Always remember: Just because it is not super exciting for you, does not mean it is not exciting for the others. They will probably learn something anyway!
We usually use an 1 hour slot to do dev critiques. Sometimes, we are done after 30 minutes, that’s totally fine.
What about pull requests?
Dev critiques are a great tool and so are pull requests. We now use both of them.
Pull requests are great for a defined scope/feature. Because you see a diff, they also help to catch potential bugs and code improvements in general, e.g. the renaming of a function. However, if we can get the feeling that there might be a broader issue inside a pull request, we try to discuss it in person or via Zoom. It is way more efficient to talk about issues than commenting back and forth in a pull request. Been there, done that.
Dev critiques are better for broader topics. For example, you can talk about the challenges you had when writing the code and about the structure in general. It will also bring up helpful discussions about potential improvements for the future. There are always ideas that come up!
Dev critiques were a great starting point for talking about code and we still love doing them. We always come up with new ideas and everyone is a tiny bit smarter after the meeting than before.