Elevator Pitch
If you write code, you should review code. That’s it. That’s the talk.
Just kidding!
Let’s discuss the code review process: what it is, what it isn’t, and how to make it more than the blind rubber stamp approvals we’ve grown used to.
Description
If you write code, you should review code. That’s it. That’s the talk.
There are quite a few “reasons” why developers at various levels find themselves code-review averse: impostor syndrome, time constraints, and area of expertise are a few I’ve heard from newbies to seasoned devs. For code owners and project leads, it’s a constant battle.
But it shouldn’t be! It doesn’t have to be!
Let’s discuss the benefits of reviewing code, what it is, what it isn’t, and how to make it more than the blind rubber stamp approvals we’ve grown used to. I’ll show you my process and things that have helped me cultivate totally awesome code reviewers!
Notes
I’m a lead developer in a 2,000+ employee software architecture and engineering practice passionate about efficiently getting to know a codebase. The code review process is not open season for bashing devs and their code; it’s a forum for sharing knowledge, learning new things, and finding the most feasible, maintainable, and performant solutions.
Everyone who contributes to the codebase should help review the code coming in (not just code owners and leads). No one’s process is exactly the same as that of the next person’s, but they should have a process that aligns with their area(s) of expertise and maintains the quality of the codebase. For example, I identify as a backend-heavy full-stack developer – I can Vanilla JS and CSS all day, but more than that (quickly) requires one of my go-to FEDs. However, I can identify when a CSS update isn’t properly scoped, spot flawed logic, track down unused variables, and recognize inconsistent patterns.
In this talk, I’ll walk through my own process, provide tips and resources for developing your own process, and offer examples of how I’ve been able to encourage my teams to get comfortable and confident asking questions and providing feedback on pull requests.