Slashdot Mirror
Code Reviews vs. Pair Programming (mavenhive.in)
An anonymous reader writes: I've spent nine years working in teams which religiously follow pair programming. I'm used to working that way and appreciate the benefits it brings. We didn't have the luxury of pair programming all the time in my last project. This required us to do code reviews to ensure the quality of the code we delivered. This post is an attempt to consolidate the upsides and downsides of doing code reviews instead of pair programming in my three months of experience.
(Going anonymous)
You are likely running this through a cultural filter.
The Indian teams that I have worked with are a lot more about huddling around a computer working things out, than the typical US approach of developer with headphones collaborating a couple of times a day. Different cultures do things differently.
Looking at *real* salary information between two geos (Bangalore and Silicon Valley) comes out roughly as follows.
Architect level 2:1.
Junior level 5:1
You can have pair programming for junior staff and still have a very strong cost advantage in India. That cost advantage plus a cultural tendency would make pair programming fairly easy to apply.
Not making any comment about the quality of code or quality of engineers on either side of the pacific...
Watching someone else code is the most maddening thing. They always seem to take the long way of doing something; use the mouse and doing eight clicks where a keyboard shortcut would do, etc. I do my best to not watch people code when I'm trying to help them. I would have killed someone years ago if I did that full time.
-SaNo