At Google the worst offenders for broken builds & minor bugs were often the most experienced & productive devs. They developed reputations around their particular teams, which meant their teammates would think "Oh, X wrote this, he usually knows what he's doing, so I don't have to be quite as careful with the review." As a result, a bunch of silly mistakes would make it through. I had one (very productive) coworker who would slip intentional bugs or style violations into his changes to see if the reviewer was paying attention.
Strangely, this didn't hold for major bugs, which were often done by newbies to the codebase. Major bugs are often created by not understanding the implications of a change or the other systems that might be impacted; experienced devs usually know this by heart, so they don't screw it up in their designs.
> I had one (very productive) coworker who would slip intentional bugs or style violations into his changes to see if the reviewer was paying attention.
I've heard of this process ("bebugging", the opposite of "debugging") being used for statistical QA analysis. If you purposely inject 10 bugs (don't forget to remove them! :) and QA or fuzzing finds 7 of them plus (say) 42 other bugs, then you can extrapolate that you have about 18 undiscovered bugs (10/7*42-42 = 18). This assumes your 10 injected bugs are representative of the actual bugs you find, which is harder than it sounds.
