Code Review
February 19, 2020
Learning security one code review at a time
Photo by Philipp Katzenberger on Unsplash This is the second in a series of guest posts by Andrew Tate, a writer turned software developer at Animalz.By Lyal Avery
February 2, 2020
How Lyft Does Code Review
With its liberal use of pink, signature moustaches and Undercover Lyft video series, Lyft has always branded itself as the fun-loving and friendly rideshare service.By Lyal Avery
January 6, 2020
3 Lessons Learned from My First Week of Code Review
Photo by Jefferson Santos on Unsplash on Unsplash This is the first in a series of guest posts by Andrew Tate, a writer turned software developer at Animalz.By Lyal Avery
November 27, 2019
3 Ways That Remote Teams Make Code Review Work Across Multiple Timezones
Photo by Brooke Cagle on Unsplash
“A code review is a synchronization point among different team members and thus has the potential to block progress,” wrote Palantir engineer Robert Fink on their engineering blog. Code review can become a bottleneck if it doesn’t happen promptly—at Palantir, “on the order of hours, not days”—that prevents code from shipping.
That’s what makes code review such a challenge for remote teams, especially those split across multiple timezones. Remote teams tend to rely on asynchronous communication and workflows, because team members aren’t necessarily online at the same time. They often need to design for the inability of reviewers to promptly unblock fellow engineers by providing a code review.
We talked with several remote teams, and they shared with us three lessons that they learned in designing code review processes that work for teams with minimal or no timezone overlap at all.
By Lyal Avery
November 11, 2019
What Belongs in an Effective Code Review Checklist?
Photo by NESA by Makers on Unsplash
As engineering teams become more established, the need to formalize a code review process becomes more important. At PullRequest, we’ve observed time and time again one of the most frequented formalization practices is to compose a code review checklist that can be applied to every pull request that’s opened by the team.
However, for checklists to be effective, teams need to use them consistently and comprehensively with each code review. That imposition can make checklists controversial, especially within engineering teams that resist process.
So, what separates the good code review checklists from ineffective ones?