Your posts are read by other Sett readers. Even if you've never blogged before, people reading similar articles across the Sett network will find your post.
"I got more views in one hour than I got in a month." -Mariano
I've had an opportunity to be part of a team doing a lot of greenfield development on a new codebase at a client recently, and it's been a lot of fun. The client already has a codebase that's grown organically over a decade to meet the changing and complex needs of a highly successful company, and is in surprisingly good shape considering. Still: it's huge, incorporates several competing implementations of The One True Programming Style, the occasional flash of mad genius, and a lot of code that was written by very dedicated developers working very hard to make very tight deadlines.
The new codebase shares none of the constraints of the old one, and the team is keen to keep things as pristine as possible as long as possible. One of the best tools in our arsenal is the enforced code review. New code entering the codebase needs to have been reviewed, no exceptions - and the goal is that most of the team reviews each piece. So far it's working out spectacularly well.
LinkedIn tells me I've been working on teams that have tried to incorporate code reviews with varying degrees of success for almost 6 years now, sometimes in larger teams that were sat in the same office, sometimes in smaller ones that were internationally distributed, and sometimes when I've paid external developers to look at code I've been writing by myself for clients.
So, here's what seems to work:
Few people seem to enjoy code reviews. There's the mental effort of understanding what someone was trying to achieve, the cognitive load of understanding how a piece of the system you're not working on is meant to fit together, and it takes time away from the joyful process of actually programming.