There’s a famous quote, “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.”
As Homer might say, It’s funny because it’s true.
But how can you tell when a programmer is stuck on a problem?
One way is to pay attention to their
behavior, and if anything is out of the ordinary for a day or two, then
you know something’s up.
Another way is to scope all work such
that they should be implementable in a day, and this certainly has the
side effect of it being easy to tell when a programmer is stuck, it also
has the unwanted side effect of putting more overhead into planning —
not something anyone wants.
This is one of the areas where daily standups — properly used — can help. Weekly “status” meetings don’t invite the sort of conversation you need to uncover problems people are encountering, and normal daily standups reward papering over problems if you’re not in a high trust environment (if you are in a high trust environment people will likely tell you when they’re stuck — so before all else, think about how you can increase trust).
During a standup, most programmers aren’t going to say, “I’m stuck on X”, and it’s not because they’re afraid of getting in ‘trouble’, it’s because they don’t want to lose face in front of their peers. However, they will give hints that they’re having issues, and you can take that as an indication to follow up with them alone, away from their peers.
So how do you ask a programmer non-confrontationally if they’re stuck?
Try these:
“Hey, it looks like <that thing you’re
working on> is a bit more involved than we initially thought; who do
you think would be best able to help you make forward progress on this?”
“I
can tell that you seem frustrated by what you’re working on. I get
that. Hard problems have a way of being frustrating and draining. How
can I help, or who can I enlist to help you get un-frustrated by this?”
Use your own terms of art; but there are three things you want to communicate when dealing with programmers:
1. Programming — even things we’ve done hundreds of times before — is hard. A minor update to a library can steal days worth of effort.
2. Because it’s hard, programmers aren’t to blame when things slow down. It’s either a combination of understanding, alignment of skill to the problem domain, or general difficulty of the problem domain. If you ask direct questions, “How do we unblock you?” You’re inadvertently challenging the competency of the programmer, even if you don’t mean to (a literal programmer might say, “I’m not blocked”, even though they’ve spent a week on something they thought would take a day, and a programmer that has an ego might think their peers would think less of them if they answered truthfully).
3. You’re there to quietly help them move forward. No fuss, no muss, no loud hullabaloo about their progress. You’re there to get them unstuck, without them feeling embarrassed by it.