I hate faddish programming trends (of which Jeff posts one per week or so), but pair programming was something I fell upon by accident at my university, and loved it – when working on a tricky bit of code.
I wouldn’t want someone looking over my shoulder while I wrote some trivial bit of code (I’m good enough to not write bugs in routine code), but when I was writing a neural net spam filter with some really hairy math in it, it was beyond essential having another guy there working with me on every line of code, making sure the thing was correct.
We’ve been experimenting with something similar at work. Our plan was to move to a two week sprint model, and at the end of every spring the ‘code czar’ for that sprint would examine an SVN diff of every change between that sprint and the prior one. That sounds horrible, but we have four very experienced developers and use jalopy religiously to keep the format consistent, so it really wasn’t that bad. The czar’s job was just to look for any WTFs and bring it to the attention of the group in a final sprint review.
It worked well for the first few sprints. We only fell off it because our scrum master screwed up and let some additional tasks creep into the sprint, then again, and then yet again, and suddenly the two week sprint was over a month and we were staring down the release deadline. But we’ve all agreed to resume the practice in the next release cycle.
Here’s one trick I found, don’t call it code review call it code proofreading. Many developers have had bad experiences with code review at past jobs, so you’ll get resistance. And many non-technical managers either won’t get the idea or think you’re wasting time.
But everyone understands the need to proof read written stuff; so making the jump to code is easier. To the developers, proof reading sounds less threatening than review. And managers will understand the need to proof read stuff that is being sent to clients.
Yes Jeff, I totally agree.
Its always good to have someone looking over your code.
Especially if you have to work on several projects on the same time.
Sometimes it makes even sense to speak about your code with someone who isnt a developer but has a good logical understanding, maybe you see then yourself where you can archive some optimizations.
On the last projects (like the one i have submitted at Website:) i often speak with the other developer about the code i was going to check in.
Currently im working all alone on some projects. So who wants to be my Coding Buddy?
What about the ladies? You forgot the girl geeks! We have coding buddies, too, you know! I work with another woman programmer, and we continually check up on each other’s code. Here’s a few you could have included:
Thelma and Louise
Lucy and Ethel
Cagney and Lacey
Wilma and Betty
Laverne and Shirley
At my current work, they just enforced the rule to show the changelists (we use Perforce VCS) to a senior developer before submitting it.
Which often results in changing this and that before.
Even senior developers, even project managers follow this rule.
And changelist descriptions include the initials of the reviewer.
While it doesn’t eliminate all mistakes, it catches a good number of errors, poor designs, forgotten internal rules, etc.
How about those projects which fail before they get to the coding stage? The efference downstream from poor design is usually almost impossible to fix at the implementation level. Perhaps we need design buddies at the cocktail napkin or whiteboard stage. There’s also the allied problem of independent peer-review of management.
the pair programming initiative is a way of using both sides of a human brain, while the one person is coding , mostly the left brain is used to figure out the logic. whilst the person on the viewing side is using a right brain perspective to evaluate the code being created by the left brain.
and like in the article , i find the comparison between pair programming and super hero side kicks a great one. because thats just what happens, when someone is in trouble , the other can help, and vice versa.
i have started working in pair forms for 3 months now, at first it is difficult to be open, and be decisive over an idea. at first i may seem struggling or difficult, or that one person is dragging the other. but thats how it is for the first part , give it one or two weeks. and if it still doesnt work , think about getting a different partner , or try and spend more time with your partner , to better know him/her.
from my experience i can truly say that pair programming is the best way of putting a lot of requirements on it and allowing them to cope under any circumstances , and to be ready for deadline. most SOLO programmers tend to get stuck on a single issue, and waste time.
rather then getting 100% from 1 person , get 1% from 100.
I think it’s important to see there are two ways of peer-reviewing.
Jeff is clearly talking about the right way. One-on-one reviews purely targeted at improving code and sharing knowledge. Its very important to do these type of reviews one-on-one.
The traditional style of reviewing is usually whole-team-against-one. These type of reviews usually don’t improve code, usually cost lots of time, often result in hostilities between team members and are usually done to give management ammo to fire developers.
So be aware. If your code reviews are taking place in a conference room instead of behind a workstation you’re probably in for trouble.
I agree with what you have said and it holds true in non-software related activities also.
For example, the effectiveness of a two person military unit compared to just a one person unit increases more than the expected 50%.
This is no magic formula, it is human nature - 2 brains are better than one.
In case of software writing, you have to decide at which point to apply the principle: during coding, after a code block is written, after it is checked in, etc
Secondly, you have to decide what you mean by ‘better code’: improve your skills, optimisation, functionality, etc
And adhere to this rule when finding a buddy: be the worst musician/guy in the band (from Chad Fowler who read it from guitarist, Pat Metheny)
