in reply to Advocacy of code reviews: how the heck do you do it?
I like closures, for instance -- the java-jocks wouldn't understand them and would call them wrong. Same with dispatch tables, etc. The more academic or twisted you get, the more you get into a position where you know the difference between right and wrong, and sometimes junior programmers or language-centric programmers shouldn't be in the fold deciding what is or isn't good. OO purists are especially bad at this... and it's worse because there are differing styles of OO.
Do you want to make everyone's code the same? That's what you should be asking. It's better to foster culture of wanting to help each other and collaborate, so you get (effectively) real group ownership and such. Then it will be continuous. Code-review sessions will turn into chest thumping in my opinion.
I guess what I'm saying is, when the love of code and design is there, it all just happens. When someone isn't in coding for the love, it won't happen, and they'll just write bad code. Not just globals, not just sphagetti code, but ravioli code as well. Some people just don't care... and I hate being jaded about it, but they just don't care about learning more. Coding isn't rigid, it should flow. And working with people who can't think the way you think (I'm not saying don't think alike -- it's good that they don't think alike), is just going to cause problems. Big ones. It will eventually cause the apathy to spread to you.
Write good code yourself and enjoy it, and maybe your beautiful code will spread to others, maybe not, but maybe. But making people think for themselves ... whoa, that's hard...
Ugh, incoherrant post. I guess what I'm saying is that with the right people, it all just happens -- and the wrong people are always the wrong people.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: Advocacy of code reviews: how the heck do you do it?
by stvn (Monsignor) on Oct 18, 2004 at 19:20 UTC |