Ok, gang, next question: what do y'all think are the best processes to improve the quality of the code the (corporate) team produces?
(The cult of quality question was good, but I'm looking for specific suggestions of things we can do.)
Background: the team is diverse, in the usual way:
There's the brilliant coder whose code is impenetrable and undocumented and whose ability to communicate isn't as good, which manifests itself as impatience or excuses of busy-ness.
There's the middle-of-the-road developer who just wants to get his/her work done and go home. New methodologies would be ok, but he/she won't initiate.
There's the person who really doesn't want to change (i.e., is hostile to change, for whatever reason), satisfied with their current level (the old way).
There's the person who really doesn't know what the possibilities are, they're just copying everybody else's code (and that works, too).
There's me, of course, the handsome, charming, brilliant developer who takes the time to write good, clear documentation and unit tests and just wants the best for the group and isn't satisfied with the status quo (technologically) and couldn't possibly be the problem.
There are all these beautiful principles out there: OOP (highly coherent, loosely coupled), functional programming (what I mostly see here is /no side effects or in-out parameters/), strong static typing (no runtime type errors, method not found, etc.), separation of concerns (business logic separate from UI and database).
And there's the old school of huge blobs of code that do multiple things all sort of intertwingled together, and global variables and their cousins the singletons and the huge classes with lots of data members.
So, how do we get from point A to point B? Grass roots suggestions get ignored. [edit: well, to be more accurate, a single developer running around telling people what they're doing wrong is not the best way, from both managers' and peers' points of view. I don't do that because I don't want to be Cassandra.]
Can we do abbreviated code reviews? Like... just call out what your new classes and methods are (ignoring implementations). Or call out (in English) where you added new functionality (i.e., which method did you update to do what)?
What if the person(s) who need to review that stuff are constantly in meetings (you know how that goes: new features, partnering, crazy deep bugs that have important customers screaming)? Would a wiki or some sort of social thing work, to get more eyes on the new designs? How do we get those who don't want to be involved involved?
So... lightweight, sustainable, effective processes? Any ideas? What works for y'all? (I know people are going to say pair programming. Ok, granted, but that ain't gonna fly here.)
 Ok, overblown language. s/screaming/focused on particular bugs/