[sergiosgc]

Code reviews. I can't stress enough the importance of code reviews to bring developers aboard a team. They are as important to junior developers as they are to senior developers. It's just that you can wean off senior developers quicker (if you wish to).

When people imagine code reviews, they imagine people analyzing code and haggling about coding guidelines. They are much more than that.

Code reviews are more about the meeting point and the excuse to talk about the software than they are about actually reviewing code. For projects less sensitive to bugs, my code reviews are not about trying to spot off-by-ones or buffer overflows. They are about discussing the problem, as perceived by the developer, possible mismatches between the developer's interpretation and the actual problem, the designed solution, how it fits the problem and how it fits the overall architecture, as well as the actual code.

The actual code review style can be as informal as an end-of-day five minute talk with each developer, all the way to the formal end-of-week review of work done. Have them fit your culture.

In the end, all that it matters, is: keep your team talking.

[balabaster]

Perhaps I'm missing your meaning: "It's just that you can wean off senior developers quicker"

Code reviews are just as necessary for senior devs, but it's more about helping everyone to understand what just happened and why: Here's the problem, here's what I did to resolve it, here are the pieces of the system it touches.

That way at least one other developer is in the loop. Two heads are always better than one. Someone else might spot something you've missed... and worst case scenario, if I get hit by a bus tomorrow, someone else knows what I did and there's less of a chance that someone will have to spend a week wading through my code trying to reverse engineer what I just did.

[mod]

The last point is really not a good one.

It would clearly be better to have the chance someone spends a week wading through your code than explaining all the changes you made to avoid that happening. You'll spend more than a week doing that.

I don't disagree with your other points, though. Two heads are better than one, and code reviews are important for a slew of reasons at all levels.

[markbernard]

Not really. Trying to explain your code to someone else helps you understand better as much as it helps someone else to understand it. You only explain it at a high level unless there is a complicated part that you might then go through line by line.

[sergiosgc]

What I mean is that if you do not see permanent value in code reviews, at least the onboarding aspect should be considered undisputabe.

[bbcbasic]

We also do design reviews where I work. The good thing about this is it saves time if you fix a bug or bad implementation at design time rather than waiting for all of the code to be written.