Thanks to Tyson Fury vs. Deontay Wilder 3 causing me to stay up until 1:30am Saturday night, I am beat this morning. It was well worth it. I am hoping a good workout and some caffeine will help before the real work of the day begins.

I have found myself spending more and more time reviewing PRs, which has been a great experience. This doesn't feel like it is cutting into my other work and is helping me keep up with my team and get a better understanding of the project as a whole. By time-boxing it to an hour or two a day, I can ensure that I have time to fulfill my personal responsibilities while still being accountable to the team. To me, the biggest benefit of PR review besides QA and bug mitigation is the sharing of knowledge.

A good PR should cleanly explain what the changes are, why they were made, and what issues still exist in the affected code or linger around the edges. This gives the reviewer a clear picture of the motivation, allowing them to more easily see if the code completes its objectives. The why gives insight into that developer's perspective on the project as a whole, the issue in specific, and their general problem solving approach. This can be incredibly insightful, especially as a relatively new engineer, as it provides a clear window into how my colleagues see things. When done well, this can be a direct transfer of skills and knowledge that allows the reviewer to become a better developer themselves.

Finishing with the remaining issues and other concerns helps share that developer's perspective on what work still has to be done. This spreads project specific information which can help eliminate borders in knowledge. It is never good to have a part of the code that "only X understands, go ask them". While levels of expertise and understanding vary, everyone on the team should have a minimally workable understanding of each part of the codebase. This makes the team more resilient to outside events while again pushing each member's boundaries and ultimately making them better at what they do.

If a team can consistently open concise, well explained PRs that provide meaningful information and definitive improvements to their project, both the final product and the engineers themselves will improve. Do this for a period of time and a deeply valuable product and team can be built. To be kitschy:

software development is about developing software as much as it is about developing the people who create it