I'll agree that while a project is being bootstrapped, peer code review could be cumbersome. Once a project has matured enough, some amount of code review, done

I'll agree that while a project is being bootstrapped, peer code review could be cumbersome. Once a project has matured enough, some amount of code review, done incrementally, shouldn't be a burden. At that point, if you're typing out reams of code every day, you might be doing it wrong ( something code review could help catch [ e.g., "Library X does this; you don't have to re-implement it" ] ). The point would not be to circle back after 100 hours of work to review, but rather every (say) 10. I don't agree that source code is not meant to be examined ( but maybe we work in totally different fields ). I regularly read source code from my coworkers, and they regularly have to read mine. Often, the developer who wrote the code is not available for questions, or isn't with the company any longer. My own code might as well have been written by another developer if I look at it after about a year. All these issues could be mitigated or muted by another set of eyes, either by sharing the knowledge ( "Why did Bob do this?" might be answered by someone else who'd reviewed the code ) or by asking the questions initially ( "Bob, why did you do it that way?" Bob: "Because of X -- I'll leave a comment in the source ).