Any good advice for managing junior developers?

In my experience I have found that loose definitions of work to be completed yields poor results. Honestly, sometimes I wonder if I have to write the code structure and leave a bunch of TODO comments for people to fill in.

Or alternatively people get going on tangents without thinking of the concrete problem given.

Or go try building generic abstractions that are unneeded and will not be reused complicating even the simplest use case.

Maybe the problem is in me and that I am not clear in communicating what's needed. What techniques do you guys use to get more or less what you want?

Best technique is to do it yourself

@trickory That's the opposite of what I am trying to achieve.

Just explain and document everything that is trying to be achieved as clearly as possible without actually doing all the work yourself, and offer support when and where it’s needed.

If you do stand ups on a regular (daily) basis that’s a good time to see if they’re is anything falling behind that you can assist with, but don’t get all in their face with constant checkups throughout the day, let them have “some” freedom.

If as you say they are going out on tangents, try to kill those quickly unless they’re related to the current project / issues.

Being juniors they’ll take some time to get into the rhythm of things but that’s normal.

There are a few things I'd do:
- first, see if you don't have a recruitment problem: accepting unqualified devs (if you have to write the code structure with TODOs comments, that's a huge red flag)
- mandatory code reviews, where you point every single thing that's not perfectly done. It will take a long time at the beginning, but do that for a year and you won't have much to say anymore (and if they can't take a harsh code review, they are not fit to work in a team)
- make yourself available at all time. Even if they bother you at the worst possible time. Even if you don't want to. Even if the question is stupid
- moreover, check in often (at least twice a day, maybe more) to ensure they are not stuck or going in the wrong direction

Good luck. It's hard work, but it pays off. Or you find out quickly it won't work ever.

Create a best case document with technologies for the tasks they assigned to. (To prevent research and prototype rime of the bad alternatives)

Junior != Bad.

Manage them as little as possible, let them make the big decisions on less important projects / tasks.

Having them go down a suboptimal path is better than spoonfeeding them.

@ItsNotMyFault That's what I wanted to do as well. But in the end we need to have a result of which we can feel comfortable with.