@David S
You can hire an outsider for a few hours per week.
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.
You forgot
wallace and gromit
penn and teller
thing one and thing two
Aubrey and Maturin
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
1 Like
You forgot Bartles James.
Bonnie and Clyde too⌠Partners in crime.
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.
+1 for the tango cash reference.
Sadly, I am the only developer where I am. 
Donât forget the famous law team of:
Dewey, Cheatham, Howe
Calvin and Hobbes
Many great couples like French and Saunders, and Starsky and Hutch are mentioned but Peppi and Kokki are the best!
I had an imaginary coding buddy but he ran off with my imaginary wife.
Jeff -
Courtney Walsh and Curtly Ambrose.
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.
- Lepto
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)
Stijn.
@Lepto Spirosis: what?!? people still use the waterfall development model?!
I think code reviews have three main benefits.
-
The maintainability of the reviewed code increases. (I donât think one can find many bugs by code reviewing.
-
Sharing of technical knowledge. You always learn something when you review code (for example: some kind of handy method of a library class you donât use). And you always see things that can be done better. So the reviewed learns from the reviewer and the reviewer learns from the reviewed.
-
Sharing how a application works. If you have reviewed the code of you colleague it becomes easier to maintain his/her applications when he/she leaves.
Developers who think the way you were explaining âŚtalking in terms of coder should know everything and be perfect should be immediately fired. If they have that kind of negative non-team oriented attitude, put them in a box and ship them to Afghanistan.