Beware Of The Second Worst Programmer
The explanation for the idea is that everyone on the team knows who the worst programmer is, so senior developers are closely monitoring everything that he does and cleaning up problems. The work of the second worst programmer is not monitored with that attention so he has the chance to do some real damage.
Although the story was intended as a joke, it is not completely without merit. Of course, just watching that person as well is not going to solve the problem. The moral of the story is, I think, that code and design reviews need to be done periodically. Most teams I’ve worked with in the past don’t take code reviews seriously, but that is one of the key practices to prevent problems and should not be skipped. Pair programming helps a lot since at least two people are working on the same task, but it still does not protect against problematic code (especially if the worst and the second worst guy pair up).
Drawing a parallel between writing and coding, proof-readers and copy-editors play a crucial role in any magazine or publishing company. They look at the stuff that you have written, identify and sort out (or suggest sorting out) language and grammar issues and look out for stuff that is expressed overly complicated and should be made more clear. An impartial view on the stuff that an author has written often helps a lot to make his text easier to understand and read.
Code reviews matter. Do them often, read code that other people wrote and get them to read your code. Step back for a moment and switch to reading mode rather than writing and check if the stuff can be written simpler or better. Even with the best intentions, people sometimes get blind to unnecessary complexity that they wrote themselves and an objective opinion of another developer can help a lot to sort things like that out. And of course, they might spot things that you have missed while writing the code, intercept bugs and suggest additional unit tests to check potential problems.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)