In 2008, GitHub revolutionized how we approached code by introducing its Pull-Request model for code reviews. Initially adopted by open-source projects, they were used as checks to review the code from possibly anonymous contributors and make sure they made the product better. Fast forward to today, while this model has been widely adopted, its potential is not fully harnessed, as reviews continue to be used as mere checks. For high-performing teams, the stakes are higher. Beyond checking code quality, they foster collaboration, continuous learning, and knowledge sharing. These are first-class concerns for engineering managers and tech leaders.
Knowledge sharing is the engine driving efficiency, agility, innovation, and growth. Rethink your approach to code reviews. View them not just as a procedural step, but as a platform to amplify knowledge sharing:
- Prioritize discussions on coding standards and best practices, primarily in Pull/Merge Requests’ comments. Remember: Every comment is an opportunity to elevate, not just evaluate.
- Limit immediate discussions to issues that hinder code from being production-ready. File away secondary discussions for later, asynchronous engagements.
Imagine if every code review taught something new to your whole team.
Maximizing the Impact of Code Reviews
Previously, we did a deep dive into the 'Ship/Show/Ask' framework, which empowers Pull Request authors to determine one of the following next steps:
- No review is needed for trivial changes (Ship)
- Share code changes with peers for feedback (Show). Note: feedback can be provided after the merge.
- Seek a review for significant/critical code changes (Ask)
In code review, spotlight potential bugs, security/legal concerns, ensuring resolution before deployment. One oversight? Code review feedback often remains confined to the author, leaving the team in the dark. Relevant insights should be accessible to all. Moreover, tech leaders often complain about the need to explain the same concepts in 1:1 threads repeatedly.
Furthermore, discussions on code readability or maintainability should ideally be deferred. Why? These conversations typically involve broader team perspectives and, when prematurely debated, can derail the development flow, and increase the lead time for change.
So, when's the ideal time for these high-stake discussions? Enter: Practice Reviews.
Harnessing the Power of Practice Reviews
Think of practice reviews as collaborative spaces for developers, whether in teams or broader communities (guilds, community of practice, …), aimed at:
- Fostering knowledge-sharing and discussions about coding practices
- Formulating and aligning with new coding standards
- Leveraging and sharing developer expertise
NB: Note that a coding practice can address topics such as a programming language, a framework, security, architecture, design, performance, and more.
Scheduled regularly (perhaps weekly or bi-weekly) and clocking in at around an hour, practice reviews are disconnected from the code release process, and address source code that may have been already pushed into production. Unlike code reviews, they have no impact on the lead time.
The practices review’s agenda includes source code snippets annotated with a suggestion of coding practices, a discussion topic, or a question. These insights can come from code reviews, coding session, or virtually anywhere.
Each insight is introduced by its contributor, paving the way for team discussions, clarifications, and collective learning. By session end, the team not only adopts new coding standards but also amplifies its shared technical expertise. To go further, check how Ubisoft gets value from these practice reviews.
Code Reviews and Practice Reviews: A Synergy
Code reviews are focused 1:1 discussions, ensuring code-readiness for production, typically multiple times weekly. They drive asynchronous interactions. As code reviews block the delivery process, they pressure developers and prevent them from diving into deeper discussions about coding practices, so they lose a chance to elevate as a team.
In contrast, practice reviews are team-centric workshops. Held weekly or several times per month, they combine asynchronous code insights from code reviews or code changes with synchronous discussions. This approach enhances knowledge sharing and refines coding standards. Inversely to code reviews, they don’t block the delivery process, so developers are freed from any constraint and can dive deep into technical discussions with their team.
Over time, practice reviews not only improve the overall code quality but streamline subsequent code reviews. Ensuring all developers know your coding standards brings confidence that the source code will gain consistency and will be easier to maintain.
For engineering managers and tech leaders, practice reviews are a powerful ally to foster collaboration, continuous learning, and knowledge sharing among software engineers.
Introducing Packmind for practice reviews
Recognizing the huge upside for development teams, we have built Packmind (ex-Promyze) as your partner to foster knowledge sharing and manage coding practices. Seamlessly integrated with your IDEs, code review platforms, and code repository, it offers a platform for sharing insights and curate coding practices. Example: A coding practice queued for a practice review:
In addition, the Packmind platform proactively scans for coding practices within your IDEs or during code reviews, providing an immediate feedback loop to developers. The development team remains in sync with the evolving best practices, fostering a culture of continuous learning.
Discover more about Packmind and embark on your practice review journey here 🚀.
Top comments (0)