[zo1]

I agree with you fully, in theory.

However, you have to understand that not all places have the luxury of their junior developers being that competent. We've tried, and we've been bitten many times. I've done it a few times myself since I started managing a team. I give them responsibility, lee-way to make their little "component" how they deem (obviously sticking to basic coding standards, at least), and ample time to complete the work. Senior developers are also at their disposal to answer questions that may arise, or even plain design advice.

And even after all of that, we're left with a steaming pile of half-copy-pasted-from-elsewhere code that's been kludged together and barely works. Some of the code is just there because it was in the sample code, others are just leftovers from failed attempts. Almost as if they kept throwing code at the problem until it "worked". They don't even bother to take a cursory look at the framework method/function that they're utilizing to maybe understand what it does, if not how or why it does so.

I don't know, perhaps we're not doing something right as well. Or maybe we're just unlucky that we have quite a string of dud junior developers. Or perhaps I'm just ranting.

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

[jlees]

Well, junior developers are just that: junior. That definition can range from 'just finished a coding bootcamp' to '4 years of CS with a bunch of practical internships'. Depending where a developer is on that spectrum, they may behave very differently when given a problem and a bunch of time to solve it.

For example, they might not realise that they should be looking into the framework. They may be scared to ask stupid questions because they don't think they deserve the job in the first place. They got a bit of harsh feedback from someone who didn't take their level into account, and mentioned a whole bunch of things they'd never heard of before, and now they're running around in circles panicking. But not saying anything about it.

Obviously a lot of this boils down to "it depends on the person" and none of this may be true. But here are a few thoughts:

Take a step back and think about what the expectations are and whether those are communicated at all. Assign a specific senior developer as an active mentor, and coach them on how to give constructive feedback if they aren't very good at it (it's a growth opportunity for them). Suggest reading lists, talks, and examples of best practices - including stuff that makes working on a team smoother, like source control, etc. Pair program for the first week or two. Code reviews (as small as possible), design reviews, and even giving them less freedom at first so they get confident rather than overwhelmed. Check in frequently so you don't get a steaming pile that could hopefully have been avoided :)

[trcollinson]

Out of curiosity, how do you handle things like testing, continuous integration, and code review? I have found, as I stated in another comment, that these sorts of things help quite a bit. Developers will more often than not rise to the occasion when told they need to test and be ready for continuous integration. The only thing I have found useful is to draw the line between ample time and too much time. This comes down to tasking appropriately in small chunks. If the cadence of development in the groups is that, on average, you get two things a day integrated, then I have found that engineers will ask more questions and make better decisions.

[zo1]

We have unit-testing for framework-level code, which is more often written by a senior developer. Continuous integration builds happen every half-hour I think, so we quickly pick up if someone pushed something that breaks the compilation or build process. Though, at that level, I should point out that quite a lot of our business code is written in python, so even basic syntax errors go through further than they should. In this department, I'm pushing for getting lint-checking via Sonarqube integrated into our CI process, which is almost production ready, but delayed.

As for code-review, well to be honest, we don't have a formal process at all. It's simply been that way since before I got here. But in my unit we've managed to get buy-in from the high-ups to start off with it in the next project. So I hope that helps us quite a bit. At least, it'll help me out as I'm currently the only one that reviews code. Every once in a while when I've got down time I go through the commits, and add TODO's and comments all over the place. I've found that it makes it quite obvious to the developer if he sees such comments abundant in their code. If it's seriously bad, I speak to them personally and explain things in detail including the "why"s.

I'll definitely see if we can maybe push for unit-testing for our business code. I'd guess that that, and the incoming code-review processes will help a bit. Perhaps they'll not fight it too much when they realize that it'll increase their quality as well as their overall skill.

[JamesBarney]

Are you running into more design issues ie they didn't fully understand how to solve the problem so they are just throwing code at it? Or are you running more into code issues where the code is just sloppy?

For the first problem I would consider that after you give them a problem and they solve it have them white board it for you. Ask questions about how they handle certain edge cases or problems. If they haven't have them go back and figure it out.

For the problem with sloppy code have code reviews every few days. Just keep on asking questions about special cases, and giving advice on how to better structure code.