Have you seen this before? Your development team has just been told they need to do code review. Maybe the mandate is coming from upper management or from an industry regulation. Or maybe even from a visionary (now troublemaker) on the team itself. And although everyone agrees that releasing “better code” is a good thing, the new initiative to review each other’s code incites a cacophony of whining, wailing, and lamentation.   Let’s say you’re the group’s manager. Even though you explain to your team that code review has been consistently proven to improve code quality – effectively and efficiently – they’re still skeptical and reluctant. This reaction is entirely normal. Developers resist code review because they associate it with paperwork, meetings, overhead, inefficiency, and criticism. They often view it as an impediment to productivity rather than as a vehicle to better understand and improve the code and its design.   So you have a challenge:  how do you get your team on board so they can reap the benefits of code review? And how do you deal with the social issues that come with criticizing another person’s work? 
You would..
Share