Unfortunately I work for a big company, and our team has a ridiculous 150+ designers/developers - how anything gets done is beyond me.
Also unfortunately, it fell upon me to review as much of the code produced as possible for some time. It wasn't a horrible job, but it opened my eyes just how beginner some of these developers seemed, and to how useful code reviews can be.
I never attempted to organise tradition 'sit-down' reviews - it wouldn't have been a good use of peoples time (and 90% of the team are in india!) - I just checked out a particular module and scanned it for red flags, repeated code and attempted to build up an understanding of what it was supposed to do.
Doing that caught many design flaws and simplified many chunks of spaghetti code, not to mention abuse of the database (bad queries, unnecessary queries etc) etc, so I think it was a good use of time.
Catching design flaws at this post implementation review stage is not really productive however, as its too expensive to fix them.
My solution to that was to do white board sessions with the designers, then ask someone to write up the outcome in a couple of pages to be quickly reviewed by the other members at that meeting - doing that was essential, as the number of times miss-understandings were caught before a code editor was even opened was amazing!
So basically, I think that code reviews have their place, but my feeling is that a sit down meeting is generally overkill. I also reckon that they are much more important (perhaps exponentially so) in a large team with many potential mediocre programmers than in a startup with several much more competent hackers!
I have never tried pair programming, but I know a lot of people are fans of it - I can see how it would be useful in a big corporation when someone is implementing someone else's vision, but struggle to see how it would work in a small startup. In the startup, surely people would be trying things and molding the vision in ones head until something useful comes out? I certainly hope to give it a try someday to see how it goes ...
Also unfortunately, it fell upon me to review as much of the code produced as possible for some time. It wasn't a horrible job, but it opened my eyes just how beginner some of these developers seemed, and to how useful code reviews can be.
I never attempted to organise tradition 'sit-down' reviews - it wouldn't have been a good use of peoples time (and 90% of the team are in india!) - I just checked out a particular module and scanned it for red flags, repeated code and attempted to build up an understanding of what it was supposed to do.
Doing that caught many design flaws and simplified many chunks of spaghetti code, not to mention abuse of the database (bad queries, unnecessary queries etc) etc, so I think it was a good use of time.
Catching design flaws at this post implementation review stage is not really productive however, as its too expensive to fix them.
My solution to that was to do white board sessions with the designers, then ask someone to write up the outcome in a couple of pages to be quickly reviewed by the other members at that meeting - doing that was essential, as the number of times miss-understandings were caught before a code editor was even opened was amazing!
So basically, I think that code reviews have their place, but my feeling is that a sit down meeting is generally overkill. I also reckon that they are much more important (perhaps exponentially so) in a large team with many potential mediocre programmers than in a startup with several much more competent hackers!
I have never tried pair programming, but I know a lot of people are fans of it - I can see how it would be useful in a big corporation when someone is implementing someone else's vision, but struggle to see how it would work in a small startup. In the startup, surely people would be trying things and molding the vision in ones head until something useful comes out? I certainly hope to give it a try someday to see how it goes ...