Our group requires code reviews before committing code. A minimum of 1 reviewer, but there may be multiple reviewers, especially if the change crosses into another developer’s specialized area. Also when the product is close to shipping, 2 reviewers becomes the minimum.
The core of our group has been together for over 20+ years across multiple companies and we have been doing code reviews all along. Life got a lot easier when graphical side-by-side visual difference tools came along (I am partial to vimdiff with cscope integration myself).
I’ve never worked in a place that did nice code reviews… Out of my last three jobs, my current one we don’t do teamwork at all. I look at almost every check in done (easier in 2015 as I was the only one ever checking code in) and sometimes email quick feedback. One developer used to just yell at me that if I had a problem with his code it was my problem and I was too stupid to understand it. Or if it was something I thought was a bug, it was my problem and I should fix it.
My previous job we did 99% of our work pair programming, so everything was basically reviewed by someone else as it was being made. And no one owned any part of the code, everyone worked on everything so things mostly got checked out by other developers at some point…
And where I worked for 10 years, before that, we tried it, but code reviews, involving ten to twelve people, plus a couple of managers, usually turned into three and four hour conference calls and changes in specifications and UI reviews and problems about wrong fonts and wrong colors and how screens would never work for users, and grammar in in-line comments… It was very inefficient and unproductive. If the boss popped in there would usually be all new requirements because he’d just spent the previous weekend visiting at one of our major customers’ houses for a barbecue and chit-chat about how the program should function differently.
Bob Harris
September 28, 2015 at 9:20 amOur group requires code reviews before committing code. A minimum of 1 reviewer, but there may be multiple reviewers, especially if the change crosses into another developer’s specialized area. Also when the product is close to shipping, 2 reviewers becomes the minimum.
The core of our group has been together for over 20+ years across multiple companies and we have been doing code reviews all along. Life got a lot easier when graphical side-by-side visual difference tools came along (I am partial to vimdiff with cscope integration myself).
Kevin Rubin
January 17, 2016 at 7:27 pmI’ve never worked in a place that did nice code reviews… Out of my last three jobs, my current one we don’t do teamwork at all. I look at almost every check in done (easier in 2015 as I was the only one ever checking code in) and sometimes email quick feedback. One developer used to just yell at me that if I had a problem with his code it was my problem and I was too stupid to understand it. Or if it was something I thought was a bug, it was my problem and I should fix it.
My previous job we did 99% of our work pair programming, so everything was basically reviewed by someone else as it was being made. And no one owned any part of the code, everyone worked on everything so things mostly got checked out by other developers at some point…
And where I worked for 10 years, before that, we tried it, but code reviews, involving ten to twelve people, plus a couple of managers, usually turned into three and four hour conference calls and changes in specifications and UI reviews and problems about wrong fonts and wrong colors and how screens would never work for users, and grammar in in-line comments… It was very inefficient and unproductive. If the boss popped in there would usually be all new requirements because he’d just spent the previous weekend visiting at one of our major customers’ houses for a barbecue and chit-chat about how the program should function differently.
Krishna
January 18, 2016 at 12:04 amAre you sure you didn’t work at Footle, Kevin? :)