Oh god, this is so true. Albeit I'm still not out of university, having dealt mostly with very strange assignment requirements, I noticed how the amount of crap that got past the radar greatly reduced itself when my classmates and I decided to give each other's code a look, to the point that our professor (one of the absolute best programmers I've ever known) asked us how we were doing it, and once we explained, started encouraging peer review in the other subjects he was teaching.

So yeah, peer reviews rock.

Here is an interesting article that agrees with you and goes a bit more into details about what kinds of code reviews really work:

http://a.gd/77dee2

You are Jeff, I love you.

All well and good...as long as you work in a shop with more than one programmer. I am a one-man shop. I know AT LEAST three other people in the same predicament. And don't just suggest to use each other as code reviewers...How would your manglement feel about you shipping intellectual property around the 'net to people in other shops, in some cases, actual competitors?

Cautionary tale: Being the lone wolf sounds cool, until you're the one howling by yourself in the moonlight.

Like many things, I think open-source projects have been doing this for years out of necessity even when it wasn't as popular in corporate environments.

I can't really imagine a project without some form of code review, now.

There's an interesting side-effect to getting reviews, though, which is that when I know I have to go through one, I often am a little less vigilant about my own code than I am on projects that don't involve review (like personal projects). I won't test quite as much, because the reviewer is likely going to test. I'll still usually look over my code before I submit it for review, but sometimes not as thoroughly as I would if it isn't going up for review.

Basically, a slight amount of the responsibility gets transferred to the reviewer that would normally be on me.

They're still great things to have, though, and overall I think they really do improve things. Reviewers often see things that I never would have, *even if the reviewer has less experience coding on the project than I do*.

-Max

Wow! If only I had figured out that having a successful blog involved copying & pasting 3/4ths of all your posts. Profit! Nice work.

Hi Dieseltime, I see that you are new to Coding Horror. Enjoy the archives! :)

In your list, I can't believe you'd left out the Ambiguously Gay Duo.

I figured you would have had John Carmack and John Romero

I think I've had to debug code written by Cheech and Chong :-)

@Max that's strange re lowering your standards. In my experience it has always been the opposite, knowing that people are going to review my work makes me less likely to be lazy because I know I'll be picked up on any slackness.

I wonder what other people's experience is? Maybe I'm a special case because I work on a code review tool ;)

You left out Statler and Waldorf. Seriously though... I have had the opportunity to work closely with some really cool people the last year or two and it helped greatly to be sharing ideas and looking at the code to implement the ideas together. Talking through what you're thinking about with someone else who's head is in the same space is always a good idea

As a lone gunman for 10 of my 11 years in programming I have found peer reviews to be frivolous and counterproductive. I have learned nothing in a peer review that I didn't learn by myself eventually. The problem with peer reviews is that the peer review gives management "ammunition" to fire you if you don't live up to the expectations of even one of your "peers".

You forgot to mention another great pair: Murtaugh and Riggs (http://en.wikipedia.org/wiki/Lethal_Weapon) :)

> The problem with peer reviews is that the peer review gives management "ammunition" to fire you if you don't live up to the expectations of even one of your "peers".

1) the point of peer review is not to give "ammunition" but feedback to you. At a sane organization, anyway.

2) I advocate picking your own peer review buddy, for the most part, so you enjoy the experience.

Very much disagree with Max - reviewing other people's work is one of my responsibilities as one of the more experienced team members, and I'd be seriously concerned if it looked to me that they were getting careless, expecting me to save them. If the coder is doing their job properly, the reviewer shouldn't be doing anything more than suggesting ways something could be done better, not ways it's been done wrong.

Batman works alone a lot too though... because his sidekicks keep getting killed... so he is probably not a good example :P

I like the term coding buddy. Having multiple eyes on code works for Lixus, why wouldn't it work for your code?

The next questions is, why after plenty of evidence that code reviews create value, improve quality, and increase velocity, do we avoid them? This is a human problem, not a procedural one.

I think you left out B.J. and the Bear, Smokey and the Bandit, Tom and Jerry, and Butch Cassidy and the Sundance Kid...

A rose is a rose by any other name? Isn't this just a form of editing? Works for writers, academic research papers and a whole host of other constructive disciplines. Why do programmers think that can just bang it out once, and have it declared perfect? Particularly when -- by most definitions -- it's the first time they ever wrote something like this.

It's a strange occupation, often growing stranger.

Paul.

Myself.

I'm currently self-employed so I'm a single developer business here. I find I can successfully review my own code by reviewing it first thing the next day.

Works better than most people would think.

Laurel and Hardy? :-O

I never get anything reviewed because nothing i ever code is final. :) One day perhaps.

Yeah self reviewing the next day does seem to work quite well although I am sure it doesn't hurt having another pair of eyes.

Probably my favorite post you have done.

http://www.ralphedge.com/

buddy.

I am the only person in my company that does Ruby on Rails development. Are their any place online to find people to review your code. Like a stackoverflow.com for code review?

This is SO true! Thanks for putting it out there!

@Chad Moran:
I'm with you in this one, i do the exact same thing, start codding all day long, and in the next morning review my old code, i have to say it works great for me, i guess my duo is me and mini-me. I don't know if can do that with another employee at my work, they are not bat programmers, but there isn't chemistry and i don't admire them, but i realize that if I can find my perfect buddy who can successfully review my code the productivity and energy would be awesome.

At last. The false assumption that someone can be self-critical is over. You might beleive you can be self-critical, but how can you actually be self-critical if you are never fully self-aware.

Just by explaining something to someone you become aware of problems in your code. The same is true of personal skills, interpersonal skills and management skills. People don't have a great gague on what they know if they don't know what they know. People don't know they are treating others badly if they don't realise they are doing it!

People don't know how bad their management skills are because they simply aren't aware. If they had to stop and explain "why" they mange people and things the way they do - they would have the same reaction as you have explained above.

Now if you can just extend your idea out a little and accept peer driven critical (positive and negative) feedback (or better still - 360 degree feedback), THEN you can truely be "self-critical" in all areas. Your code and company will benefit.

@PaulG
> The problem with peer reviews is that the peer review gives management "ammunition" to fire you if you don't live up to the expectations of even one of your "peers".

Management should not be involved with peer review meetings - only peers should be. Not even the project manager should be part of the peer review. That way there is no holding back and no grudges held. There is also no wasted time of non-technical managers listening to technical options and tricks.

if Management are at a peer review - it isn't a peer review.

Hm... I'd like to nominate today as coding buddy day. Imagine receiving "Will you be my coding buddy?" every feb 26.

Seriously though - sharing code with another pair of eyes does wonders. You get embarrassed by your wtfs and you get a sense of pride out of clean and readable code. My current choice of coding buddy is pretty limited as there's only one other developer working here :)

Perhaps there's a niche market in this? www.findyourcodingbuddy.com?

the buddy system on school trips is i'm sure at least as much about making it easier for the teachers to be able to count the children

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.

I think code reviews have three main benefits.

1. The maintainability of the reviewed code increases. (I don't think one can find many bugs by code reviewing.

2. 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.

3. 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.

The greatest duo of all time: Wallace and Gromit!

Seriously, peer reviewing would greatly improve the code quality where I am currently working. As I'm not an employee, just a contractor, I wonder what the best method of changing the working practices of the people I work with.

Unfortunately, the people I work with don't read programming blogs so they are a tough bunch to improve to start with.

Skizz

My manager just mentioned about exactly the same thing days ago and I couldn't really agree with him as he didn't illustrate the benefits of doing so good enough, but now I see the light of it ;)
Nice one Jeff!

Hey Now Jeff,

Coding with other people is always more fun too.

Coding Horror Fan,
Catto

totally agree!

The sample chapter you're linking to is not available.

See the following link for the TOC and chapters 2 and 3:
http://www.processimpact.com/reviews_book/reviews_book.shtml

Coding Horror Aficionado,
ema

@Jim Lehmer

If you can explain you code to a non techie, it's good code. If you can't it's refactor time...

Dave

I am pretty much the only coder in our company right now, so I don't have a coding buddy. But we will probably hire another coder in a few days, so I hope he can become something like that for me:)

@Paul-Gabriel

I hope you're on the interview loop. :)

What to do if you are the best programmer in the company and everyone wants to peer with you so they get their code checked but none of them is good enough to check yours?

@Ryujin

That probably wont happen, you can always learn something. Noone knows everything. They can at least check the readibility of your code and they will learn from your code.

Many years ago there was a story going around - which may have been wildly apocryphal - that went something like this.

A software house noticed a steep decline in standards and productivity and managed to trace its roots to the sacking of a cleaner. When the programmers were asked what he used to do their replies all boiled down to:

"He asked us 'why' we were doing it that way and he listened carefully to our explanations."

Needless to say, the cleaner was rehired.

It's not the review that improves your skills, it's explaining clearly what you are doing and and why you are doing it that way. If it's clear in your mind it's clear in the code.

Paul

Beavis and Butthead

For the UK based programmers there is

Morecambe and Wise
Little and Large
Bill and Ben
French and Saunders

to name a few

For those review resisters they need to be pointed to the analogy that writing code is like writing a book or even producing a scientific article. An author will get the book edited before publication, a scientist will get their work peer-reviewed before publication.

For Dutch speaking developers there are e.g.:

Suske en Wiske
Peppi en Kokki
Q&Q
Samson en Gert

I was thinking exactly this (less eloquently, of course) when I saw your previous "Are you an Expert?" and "The Bad Apple: Group Poison".

I.e. the Wikipedia theory is that criticism from a not-so-expert is, on the whole, better than not having them around at all.

But my own experience tells me this isn't a universal rule. For one thing, having people of comparable abilities play together (e.g. chess) generally works better (i.e. advances their level more) than having people with very dissimilar abilities work together, while the latter is obviously better when the ones with higher abilities specifically focus on trying to teach rather than trying to perform themselves.

As long as this is in moderation. Buddy's can be abused by newbies looking for free teaching lessons and free bug testing. Too many times have I spoken to a Jr. programmer and convinced him that "code reviews" are not Q&A debug sessions.

What about Ace and Gary???

> Besides, who wouldn't want to be half of an awesome part-time coding dynamic duo?
That's fine as long as you're the Batman half. Robin sucks.

In the classic book "Think and Grow Rich," Napolean Hill describes that when you combine the minds of two people, the benefit is not 1 + 1, but rather 1 + 1 + 1 as the two minds "combine" to create a third - in the form of the ideas and thought patterns that are stimulated by an additional person and that would not have occured alone. I have found this to be true as well.

My coding buddy:

http://www.thinkgeek.com/geektoys/science/981b/?cpg=ab

Strangely he never disagrees with me.

I would love to do peer reviews of my code. Try convincing my boss that we should budget time in the project for it! We are almost always in a "this is what they would pay and it covers cost" situation.

>Like many things, I think open-source projects have been doing this for years out of necessity even when it wasn't as popular in corporate environments.

Not really. The real value of doing one of these peer reviews is in having you EXPLAIN it to someone else. It's amazing how many of your own mistakes you find when you actually have to go back and explain to someone how it works.

Even individual programmers can benefit from "reviewing" their own code by writing up a document explaining the code as if you were explaining it to someone else. Heck, if she REALLY loves you your wife may be willing to lend an ear (although she won't understand it).

I don't know of a single process that has improved quality for us more than simple peer reviews. The type that Jeff is advocating. Physically sit down at the programmer's computer and have him/her explain what they did. It is invaluable.

I truly wish I had a peer to review my code, but I am the only developer here. I started a blog to share my code and to get comments on it, but I am not allowed to share my work code, so that is difficult as well.

"'Anyone who needs his code reviewed shouldn't be getting paid as a software developer,' scoff some review resisters."

Heh. Sounds a lot like, "I don't document my code. If it was hard to program, it should be hard to understand."

Tango and Cash? WTF?

"'Anyone who needs his code reviewed shouldn't be getting paid as a software developer,' scoff some review resisters."

Keep an eye out for this person when you're doing your hiring. This type of mentality should be avoided at all costs. Definitely not a team player.

My team recently took on peer review as part of our general approach to process improvement, and the impact on quality it has had is phenomenal. It uncovered some long standing problems with an approach one developer had used for a couple years, brought the team closer together, and gives everyone an opportunity to learn from each other.

While the initial perception from outside the team doing the reviews was that productivity was lower and a lot of time was spent doing these reviews, at the end of the release cycle the time has been more than recaptured in reduced defects and quicker time to complete regression testing.

If you plan to do this with a team, there is a great tool from Atlassian called "Crucible" that I would highly recommend. It makes the review process much easier, and can be tied into each CVS commit.

The most productive peer reviews I have had came about not necessarily with the peers that I admired most, they were due to the relationship between the reviewer and the review-ee. Say one developer on a project wrote a web service to , and another developer writes a client that uses the service. Well now, you have a producer/consumer relationship from which a peer review on either end will benefit both developers.

I have long practiced something similar in nature. Even if you can't find someone to review your code (for whatever reason), a great way to learn is to review the code of others.

Find a programmer that is better than you, or that you at least respect greatly. This is particularly effective in areas that you aren't already well versed in. You can often learn some great things. You will often get straight to the meat, so to speak, with them having already figured out some tricks and overcome some issues that you would have to if you were to approach this from scratch.

Don't fret if you don't have someone like that. Fire up Reflector (if you don't have it, GET IT!), and disassemble some of the .NET Framework itself. There's some great stuff in there.

Karl's book is excellent and anyone wanting to implement a whole code review process should get it.

My book on lightweight peer code review (free at http://codereviewbook.com) adds more data to the picture, specifically around less formal kinds of review like just buddy-checks (as you talk about), email pass-arounds, tools, and pair-programming.

It turns out a lot of the techniques in Karl's book are unnecessary for a good ROI. Meetings, for example, take a ton of time and don't contribute much to uncovering bugs.

I was with you right up to Hall and Oates...then the wheels came of this wagon.

From your examples, you demonstrate the problem. Who wants to find out they're the Robin of the duo...

"The problem with peer reviews is that the peer review gives management "ammunition" to fire you if you don't live up to the expectations of even one of your "peers"."

Here's the truth. They decide to fire you and then look for a reason.

In the words of Doctor Cox, "Now, 'course, if you are lazy and incompetent, then, yes, that will buy you a one-way ticket out of here."
But let's be honest, they'll work that out without a code review.

@David S

You can hire an outsider for a few hours per week.

I can't believe nobody's thought of 'Who's Your Coding Daddy? I am.'

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

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

Many great couples like French and Saunders, and Starsky and Hutch are mentioned but Peppi and Kokki are the best!

Who is my coding buddy?

Cheryl Burke.

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

@Lepto Spirosis: what?!? people still use the waterfall development model?!

May I be Batman?

I think Gumby and Pokey are a bit more accurate for this (cough) profession.

I prefer having a coding bee-atch.

Jeeves and Wooster btw? Indeed, Sir ...

I've been imployed by a big, international company for many years, where I had to work alone. Now I'm a one-man shop. I simulate code reviewing by inspecting my own code not on the same day I wrote it, but, if possible, several days after. This is possible without wasting much time, because my software usually has enough separated parts, through which I can do a roundtrip. Additionally I have trained myself being able to attain a different attitude in the different phases. It works.

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.

Calvin and Hobbes

Integrity

In your article you have the line "Multiple studies show code inspections are startlingly effective.", which contains a hyperlink.

I would expect that since you are quoting, the hyperlink would be to the source of your information. In fact its a link to an article of your own.

Please Jeff, when you quote someone hyperlink them and not to yourself.

"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."

I am truly ashamed that within 20 seconds, the words "Strip Code Review" flashed across my mind.
Wait...

Code Review DRINKING GAME!

I have to admit looking back, I have regularly went back to some x-month old code which didn't live up to the expectations.

I took those occasion to improve it, adding more robustness, more (updated) design, more documentation (as the first few days it's often painful to look at code made maybe 1 year ago with no clue).

I am often surprised how much my impressions could change in just 6 months. Maybe I should prototype more and play more with the results. Too bad I lack the time and will to do so.

Having someone to review the code for me would likely be a real time-saver. We all know how difficult is to get the rid of that bad-design-that-was-not-considered-harmful after the code grows around it.

Why don't I get reviews? Because essentially good workforce is impossible to find here. I mean, good enough to understand what I needed to solve in the first place. In a small company I worked with about 5 years ago, I had to spend about 6 months in taking the others from our terrible school level to "useful" level. By the time they started producing something, we were just missing the milestone by a long shot.
Yes, it sucks SO bad here.

But the benefit of a later-time or second-programmer review is undisputed to me.

You could try to explain your work to a rubber-duck instead. :D
http://compsci.ca/blog/rubber-ducks-help-best-with-computer-science/

The kind of fast and casual code review described in the article sounds great, but there's also *bad* code review. I worked in a shop with two mandatory reviews, and it was painful. Most "bugs" caught weren't functional bugs, but style and formatting issues: what to name a variable, how to format a comment, that kind of thing. Of course the two reviewers would disagree about the "standard..."

So if you're going to do peer code review, you need to be able to let things go... the unimportant things anyway. The comic has it exactly right: if it doesn't make you think "WTF" then it's not even worth mentioning. Trust me, if you dig you'll find plenty of real bugs...

Being a Quality Assurance Analyst, I think the WTF Quality Measure should be integrated into every SDLC.

To anyone in a One-Man Shop, ask around your group. Chances are you'll find someone with enough programming experience to ask questions. Present your design and logic to them. If they WTF, then you know where to start.

This rocks!

My pair programming is looking at my code again the next day, I have a terrible memory but I'm always willing to restructure and refactor.

Jeff and Joel?

@Nicolas: if a bridge architect released a beta for testing which repeatedly crashed, he or she would soon be helping you bag your groceries. Coding's not difficult - thinking is.

Ponche and Jone Awesome lol

I've seen lots of failed attempts at code review systems in the seven startups I've worked.

In general the very worst way to review is to save up a bunch of changes, call a bunch of people into a conference room and show the code on the wall with a projector. This system absolutely brings out the worst in people and doesn't work.

The next worst system is to only code review after a bug appears that bothers the management. This makes the code review something akin to a military non-judicial punishment.

At my current shop (five devs) we've come up with a review system that works well.

The five of us have agreed that whenever possible we will not check in code until another dev reviews it. The reviews usually consist of the reviewer looking over the writer's shoulder as he displays the diffs with the current code. Eighty five percent of the time the reviewer just says 'that's fine by me'. Five percent of the time the reviewer notices a real problem that is nipped in the bug. The other ten percent of the reviews consist of the author explaining the code as he looks at the diffs, then saying , 'oh, that's not right, I'll change that before I check in', and continuing the review until the reviewer says 'that's fine by me' and walks away.

When we commit the change we prefix the commit comment with a '*' to show its been reviewed and include the reivewers name in the comment.

If for reasons beyond the dev's control he can't find a reviewer (he's working late everyone is gone) he can still commit, but prefixes the comment with a ! so that everyone knows that this commit is unreviewed.

This system works really well for us. We view these reviews as PEER reviews, not as any kind of evaluation.

Of course if your team hires a jerk then this won't work, but then nothing will. Working with a jerk on your team, especially a talented jerk, needs a post of its own.

lonely codeman

I championed the institution of a permanent "check-in partner" system at my current place of employment after seeing it used intermittently at my previous one.

Unlike pair programming, it's extremely easy to get people on board with it. It rarely amounts to more than about 3% programming time investment (assuming a day's work and a 15-minute review).

The obvious benefit is that bugs get caught before check-in, but I believe that the distribution of knowledge that check-in reviews promote is a more important benefit in the long term. Check-in partners learn good techniques from each other, maintain coding standards, and learn what code is actually going into the project.

So far, at my current shop, everyone who's been introduced to the idea likes it, which is pretty remarkable for a piece of process.

Pair programming is not necessarily an onerous regime. I think the key is to not make anything a regime.

I personally like the open source development model, with developers more or less submitting patches to the project owners. It's a good way to keep the code clean and to make the best use of the best people.

There is even a recent ms-research paper on this topic.

http://research.microsoft.com/pubs/75108/esem-begel-2008.pdf

It's hard to do a code review if there are no published guidelines or standards. Each company should have this document, which itself must be updated and reviewed regularly.

Everyone wants to be code cowboy, but best practices do exist and not everyone on a team can have it their own way. The code belongs to the company, after all.

And, each company needs someone to manage the devs. They don't need to be the best coder, but they must know how to settle disputes and pick the best path, and be able to tell the coders to "shut up, it time to move on".

> It's hard to do a code review if there are no published guidelines or standards. Each company should have this document, which itself must be updated and reviewed regularly.

You're trolling, right?

If you aren't, then I'll just say that code reviews are supposed to be informal - no guidelines beyond look at the code and make sure the guy checking it in can explain what it does.

@chris: nope.

But implying that all code reviews are informal with no guidelines beyond having someone explain what it does is exactly the opposite of what I've seen work.

well code reviews aren't the only thing, it's just a useful check on keeping bugs out of the codebase.

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.

In my project, we have adopted this practice of pair programming, we implemented it in a way so that when one is focusing on technical aspects the other one focuses on the business rules and in this way we are able to build a full proof usecase and at the same time doing code reviews.
When we started doing this, i thought we are wasting time, but i was totally wrong. This way of working definetly increases productivity and decreases the testing effort.
Thanks for the article Jeff.
Prachi

I am the best coding buddy I could have. Not necessarily because I've wanted that but out of necessity. Small team ya know.

I can't believe everyone missed Captain and Tennille! Maybe I'm just older than most of this crowd.

As for that Paul G. guy - boy you wouldn't want someone like that working in your shop!

@Ashamed

> I am truly ashamed that within 20 seconds, the words "Strip Code Review" flashed across my mind.

This is why we cannot have nice things.

Rihanna and Chris Brown

Crumbs.

I've been writing video games for a long time. The words 'code review' to me mean allowing someone to look over my work and then steal all my great ideas.

It means handing over all the clever techniques that no-one else knows how to do and sacraficing being one of the world's leading programmers and handing out stunning inspiration on a platter to anyone who wants it.

The trouble with all this code review crap is that programmers used to be held in awe, now adays the rank of programmer has been demoted from rock-star-god, film-star, super-genuis to the rank of someone working in a corner shop, any old Joe, Indian sweat shop worker, Nike Trainer maker.

Big business, greed and the lack of self respect has taken the status of programmer to nothing special. Multi billion pound companies can kiss my arse, they're only as good as WE made them. As far as I'm concerned they cal all F* OFF!

Fortunately I have a new project in mind, that will make the shit they call AI today look pretty embarrasing.

Only the best need apply to join the team.

P.S If you haven't heard of me as a programmer, don't bother applying - lol

http://caspianit.co.uk

you westerners....

Miyuki and Natsumi

I'm not going tell much, just... not another cop show :-)

On a serious note, I knew about the power of pair programming and work buddy a long time ago. If anything, the most prominent effect I have experience is how working with somebody else in real time inherently has me _paying_attention_ to the matter at hand with such focus. Left alone, my mind tends to wonder and think about other irrelevant topics (read: procrastination and distraction).

And then now, the real problem - it is just too dang difficult to find a buddy who is interested in the same topics and activties as I am. Even individuals who are self-motivated and competent have their own interests and schedule to attend to.

I absolutely loved the cartoon about code reviews showing wtf/minute, it is just as funny as it is true. A colleague of mine happened to take a look at it and did not find it funny at all. Actually I had to explain the cartoon to him. As you might imagine he is one of those who writes a lot of "wtf" code. At my workplace there are few of us that understands that cartoon so finding a coding buddy, as important as it is, is not an easy task where I work. I think i will settle for a rubber duck that I can talk to when I have a need for feedback. That way I will be guaranteed to not get the usual crappy answers :)

Hello??? Ren and Stimpy? (especially appropriate because most of the time you are saying to your partner, "Stimpy, you Eeeediot!"

Spongebob and Patrick
Oscar and Felix
Solid Snake and Raiden
Black Mage and White Mage
Aragorn and Legolas
Kirk and Spock (are you out of your Vulcan mind?)

And what for this :
http://blogs.tedneward.com/2009/02/22/As+For+Peer+Review+Code+Review.aspx ?? Can be that we developers do not have good and scientific measurement tools? Is possible that Computer Science is a child(prodigy) engineering branch in comparison to other fields such as Electronic Engineering for example?

You can get really valuable lessons with this simple practice.

We do this religiously in my team (we try to find the time for it even if apparently there is none).

Right now my coding buddy is a former trainee (he finished serving his time like a year ago) and believe me, I have got great insight of things I did not considered, potential bugs, hard to read code, event method/variable naming corrections from him. So even if you feel like a all seasoned programing veteran, there is always room for improvement if you are humble enough to take advice from your peers regardless of their credentials or "seniority".

Simon Nicol, I feel bad for you...

Programing is not a path that you can walk alone... at least not a lasting pleasant one.

70% of a good programmer skills are social, not technical.
I have worked in the game industry too and I find no resemblance of it in your words. I guess I never worked with someone you thinks we are "demoted godlike rock stars". All the people I have worked with (including myself) feel more like "mercenaries how enjoy it so much that could do it for free, but why do it for free if you can make a profit... with the exception for idealistically OpenSource projects".

I work on a development team consisting of about 25 active programmers, working on a very large insurance application that has about half-a-million lines of production Smalltalk code and probably a similar amount of unit and functional test code.

For over 5 years we've had a designated team of 5 or 6 developers acting as part-time code reviewers. Someone from this team must review every line of code - including the unit and functional tests - before it gets released to the current shared development stream.

This Code Review team has weekly meetings where issues identified during reviews performed in the previous week are discussed and shared within the team. We've seen a substantial improvement in overall code quality during the last 5 years but one of the big payoffs has been that this Code Review team has been exposed to pretty well all major aspects of our complex application. This allows us to be very effective in identifying common problems like duplicated code or code not being implemented in the ideal locations. We're also well-placed to see opportunities for framework changes that other developers, focusing on solving just the problem-de-jour, might miss.

We have had excellent support from our managers but the success of our Code Review process has been predominantly due to the efforts of the development team itself.

How about Sherlock Holmes and Dr. Watson :)

As a non native English speaker I've been calling this "pal programming" instead of "pair programming" for years =)

90% of my everyday work consists of test-driven pair programming developing. I do really little code without my current pal, and I'm getting lazy about it. I enjoy every minute we spend sharing programming achievements and frustrations with someone.

So here is a thought: what is more efficient?

- Having two programmers doing the job of one, but ensuring better code thus less debugging time.
- Have each one on their code and do some code review sessions.

Obviate childish pairs of lazy irresponsible programmers expending more time in youtube than in their code.

(I would add Asterix and Obelix to that list of famous couples)

This only works if done properly, and is done early in the process.

A place I used to work at, code reviews were done after you've done all of your work and it was supposed to be correct and accurate. If there anything they didn't like or you'd make some insane decision (because you weren't supposed to figure it all out yourself and not talk to anyone else) the senior team would complain to management.

You forgot about Hardcastle and McCormick