This post is copied over (and slightly modified) from an old blog post I wrote in 2018 on wordpress. I am planning to continue a series of posts on this topic, and felt that it would be pragmatic to have the original post copied here first. I have also altered the title slightly, to reflect the theme of the series of posts more accurately

Many times in the past, I have been asked by a number of engineers on how they can be effective at reviewing code written by others. Generally this implies on how to effectively follow up on a pull request (specially in cases where they are new to the system or tech stack), but the question could also originate from trying to understand a codebase during onboarding, and/or reading (legacy) code for rewrites/refactoring. My focus in this post is how I answer the question to the former, i.e. what are the driving factors of an effective code/PR review in a given development workflow.

One of the many problems I’ve observed in the past with how teams use SCRUM (and other prescriptive approaches under the label ‘Agile’), is the manner in which a.) planning work, and b.) delivering value is addressed. Teams would portray a segment of their delivery pipeline, showcasing a stream of technical tasks moving downstream. Planning work generally entails prioritized user stories coming in from the business, and dev teams breaking them down into technical tasks and pulling them into a workflow.

When I was young, I grew up surrounded by old computing and electronics magazines, issues from the 60’s, 70’s, and 80’s, a majority of them being the popular publication creative computing. I used to read them voraciously, during a time when PCs (mostly running Windows 3.1) were just beginning to spread into organisations, schools, the occasional library, and to a somewhat rare extent, homes.