For Dutch speaking developers there are e.g.:
Suske en Wiske
Peppi en Kokki
QQ
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.
Jeeves and Wooster btw? Indeed, Sir âŚ
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 QA 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.
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.
My coding buddy:
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.
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.
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.