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