Programming is an interesting thing to manage. It's not like you're managing a warehouse where you can tell the guy "You see that box over there? Pick it up,

Programming is an interesting thing to manage. It's not like you're managing a warehouse where you can tell the guy "You see that box over there? Pick it up, and take it over to the other side of the warehouse". Or a restaurant where you say "You see that pasta? Put it in the boiling water for X amount of time and when it's done take it out". My feeling, especially when starting with a new group of people, is the amount of time you should allow them to struggle is inversely proportional to their years of experience. In the end productivity is important, but not at the expense of creating a hostile work environment. Programmers need to be ok with creating imperfect things. Sometimes it's the only way they'll successfully iterate toward creating less imperfect things. Another interesting thing about managing programmers is it's difficult to create objective metrics by which to assess performance, which you can then easily compare to other members of the team. In other words, I can't go find the box and say "why is that box still over here? I thought I told you to put it on the other side of the warehouse?". or "Why is that pasta not in the boiling water?" At best I've only ever had a clear "sense" of where each member of the team is. Nothing I can put on a chart that shows definitively that Team Member A is performing at a higher standard than Team Member B. In this case it's critical to give the slower guys the easier tasks, and the more ambitious guys the bigger tasks. Create a tighter feedback loop for those who you see as having difficulties. And create opportunities for people to collaborate, and in the process compare themselves to others on the team. And every once in a while sit with them while they're working for maybe 15 minutes at a time. Don't expect them to do things your way, but by the end of the session offer a few suggestions. And make sure they set goals for themselves. "How long do you think it will take you to finish that?". Make a note of their goal. And then when the time is up ask them "So have you been able to finish that?" If not, what's wrong, and how can we help you? If so, then good job let's move on to the next thing. And I saw in other posts the suggestion that sometimes you should break down the tasks into smaller more digestible chunks instead of having them do that. Great suggestion. Finally, it's not an infallible metric (and in fact probably not a good measure for anything performance-related), but lines of code committed is I feel a good "BS detector". I had a guy (arguably senior, and arguably unmotivated) on a team I managed a while back who managed to commit less than 100 lines of code in a month. That's as close to an "obvious sign" that something is wrong as you will probably ever see. Writing code is what programmers are paid to do, so if they're not doing it there's no way to assess their performance.