[onion2k]

Stop treating your junior developers like monkeys who are only there to implement your brilliant ideas. That's not their job. Every developer should be able to solve problems; the more senior the developer the greater the impact and complexity of the problem they should be solving. Your job as a senior developer is to work out the high-level architecture that will contain the solutions to the smaller problems - eg solving the highest impact problems.

My advice would be to think in terms of black boxes. You should couch tasks in terms of what the developer can expect to receive through an API and what their code should output. What happens in the middle shouldn't be anything you concern yourself with. When the junior developer works out a solution they can run their idea past you, and if it sounds OK then they write the code. And then you can review their code. The minutia of implementation is not your problem any more.

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

[bitwalker]

I agree with most of this, but I don't agree that the lead should only care about inputs/outputs when it comes to a task a given dev is working on. A lead should have defined conventions for how code in the project is written, and I think it's absolutely reasonable for that to be part of handing off a task to a junior. My approach is usually something like: "Ok Paul, I'm going to have you build out feature X, Y, and Z, defined in ticket #s 1,3, and 5, see the README about coding conventions, and let me know if you need more context/detail on any of these. I'll swing by each morning for a few minutes to see how things are going"). Then beyond talking to each team member every day, we have standups to keep everyone on the same page, on whatever interval makes sense given the complexity of the project.

I think a lead should care about how their team is implementing the features they are working on, because as the lead, it's crucial that you know the ins and outs of the system - where I think we agree though is that a lead shouldn't care about how the work is done, as long as it's done within the project guidelines (coding style, consistent structure, testing, etc.).

[balabaster]

I agree to a point. As a lead developer, you should care about it all, but it's also your job to be a mentor. Give your junior devs just enough rope to hang themselves, but be close enough by and approachable enough so that they don't. A little pointer like, "think about this approach" or "don't use a dictionary here because..." or "generics will be your friend here, but beware of x, y and z".

You should be holding your junior developers accountable for writing tests for their code, ensuring that the test coverage is there, ensuring they understand what problem they're solving, ensuring they understand the approach they're taking, ensuring they understand the repercussions of the decisions they're making. This is how they advance from junior to intermediate and eventually to senior.

It is your job as the senior/lead developer to groom your junior devs to make the steps forward and eventually do your job. You shouldn't be telling them how to write the code. When picking holes in their code, it should be constructive, don't just to pick holes in it to pick holes in it, making them feel bad. The goal is to help them understand what's not up to par, why it's not up to par and what approach they can take to fix it. You should neither be writing code for them, nor should you be expecting they make every decision in the same way you would.