3

What is the best way to ensure that programmers ask for help when they get stuck on a problem, rather than spending too much time trying to figure something out when they've hit a wall?

I'm especially interested in how to optimize this with a distributed team.

Some ideas that come to mind:

  • pair programming
  • co-locating the team
  • timeboxes (after expiration, must ask for help)

Things (goals) to think about:

  • avoid developing dependence on others
  • maximize learning & knowledge transfer
  • cost of developer A's time to help vs. developer B's time to figure it out him/herself

There is also the concern that even if a developer comes up with a solution, it may be of lower quality than if they had asked for help. I believe code reviews are a good way to address this.

This question: When do you not give help to less experienced programmers? is good background reading for this one.

Improve this question
2
  • 2
    True story: About a half hour ago, I was stuck trying to fix a bug. Eventually, I took a break from banging my head against the codebase and went to browse programmers.stackexchange.com to get inspiration, and I saw this question. At least in my case, your asking of this question was the perfect way to inspire a programmer to ask for help when stuck; I probably would have gone on banging my head against the codebase for hours on my own, otherwise.
    – Trevor Powell
    Commented Jan 5, 2012 at 3:58
  • What if there's no one who's available to help?
    – Kevin Meredith
    Commented Apr 27, 2013 at 3:29

6 Answers 6

Reset to default
3

Daily scrum meeting.

Works wonders. And you have to do it anyway. More than a day stuck is a serious obstacle that must be addressed.

[BTW: "avoid developing dependence on others" is a terrible objective. Why bother? Also "cost of developer A's time to help vs. developer B's time" is a false optimization.]

Improve this answer
4
  • 1
    Having a daily scrum or standup is definitely a good idea, but you must ensure that impediments that are brought up get addressed. Many times, just voicing them is enough, but if someone mentions a problem but doesn't specifically ask for help, someone doesn't volunteer to help, or you don't have a Scrum Master that makes sure these impediments get resolved, then it's still a problem. Also, a day may be way too long to wait.
    – mkopala
    Commented Jan 5, 2012 at 0:44
  • If "you don't have a Scrum Master that makes sure these impediments get resolved," Then you've got a perfectly awful project organization. That's the first thing that needs to be fixed. If you're going to claim that a bad project organization can magically work, that's an even more serious problem that needs to be fixed.
    – S.Lott
    Commented Jan 5, 2012 at 3:06
  • 2
    This can fail when you have someone who doesn't bring up problems. I wouldn't call that a very common issue on teams that I've worked on, but I have seen it myself. So in addition to having the meeting, you need to work with people to make sure everyone's bringing up problems, concerns, and other issues in front of the team. Part of it is team culture and meeting structure, the other is individual behavior.
    – Thomas Owens ♦
    Commented Jan 5, 2012 at 13:16
  • "when you have someone who doesn't bring up problems"? On a daily basis the lack of progress becomes quite obvious. They can be almost non-verbal in a daily scrum and you will still directly perceive the lack of progress. I suppose, however, it might be possible to conceal non-progress from the team for more than a day or two, so it may be possible for this not to work. I haven't met that adroit a dissembler. Non-progress in a daily scrum rarely takes long to discover.
    – S.Lott
    Commented Jan 6, 2012 at 0:04
3

My two cents from my own experience:

No programmer ever gets stuck. They just tend to go off on tangents. Research and development tangents.

The best way to ensure that they don't go off on tangents is to separate the role of the lead programmer from the role of the manager: the lead programmer is usually someone very gifted who would rather be coding than managing other programmers. The manager needs to be someone who does little, if any, coding, and his job is to be constantly coaching the team.

That's because when left on their own, programmers tend to be oriented exclusively towards the engineering aspect of their jobs, (engineering lust?) with relative disregard towards project goals. So, it helps to have someone reminding them that there is a project to complete.

Improve this answer
3
  • 2
    Maybe programmers don't get "stuck" but certain people at certain times definitely slow down to a crawl. It's a personality thing, some developers throw their arms up and immediately run for help at the first sign of unexplainable. Some others, will start digging away layers after layers of abstractions in attempt to understand a problem and they feel that asking would be a sign that they didn't do their job. As a leader, your goal would be to help drive people from these two extremes towards a middle ground.
    – DXM
    Commented Jan 5, 2012 at 1:17
  • @DXM Yes, you are right. I should have said "research & development tangents". When they engage in overengineering mode, it is a development tangent. When they engage in digging mode, it is a research tangent. I will correct that.
    – Mike Nakis
    Commented Jan 5, 2012 at 1:21
  • @MikeNakis, as well as "overengineering mode" and "digging mode" there is of course also "voodoo programming mode", where they start changing things at random without understanding them, in the hope that it might help. :-)
    – Carson63000
    Commented Jan 5, 2012 at 4:33
2

One thing that has not been mentioned is the pomodoro technique of scheduling breaks during the work day.

www.pomodorotechnique.com

Just getting up and getting a drink of water or having a chat with someone else can be very helpful to "reset" the brain and look with somewhat fresher eyes. All other options here are great. I thought I would add this as it has helped me lots.

As a side benefit, time tracking is easier as it is now just "how many tomatoes did that take?" Multiply that by 25 and you have your answer. :)

Improve this answer
2

Do you know why people are not asking for help? Is it because asking for help is seen as a weakness; an inability to do their jobs properly? Additionally, what about people asking for help and not getting effective support?

In my view, if that sort of culture exists, you're going to have problems changing it because that is a top down issue.

Improve this answer
1

I'll contribute another two cents to this...

Happy Hour.

First off, I'll just say that I really don't know the answer as we've had similar circumstances. But it seems at the root, the issue is communications. Anything you can do to help the team communicate better and more efficiently will help. As people start talking more and more with each other, they will not be nearly as reluctant about popping off a quick instant message just to ping someone else and see if they know what the solution is. On the other hand, when your team feels like they are a bunch of strangers thrown into the same team, their communications will be very limited and some would feel that if they ask a lead or anyone else for help, they'd be "bothering" them.

And I know it can be even more difficult with distributed teams. I'm kinda stranded across two different teams. In each team, we have an out of state developer. The interesting part is that the two teams feel very different when I interact with others team members. What I noticed is that in a "better" (don't know if that's a good word, they are all good guys) team, we have a lot more random conversations. We'll talk about snow, snakes, burgers.... On the other team, everything is way too non-personal and effects of that seem to spill over into professional communications as well. We don't have as many random meetings, or chat sessions and when we do talk, everyone tries to steer clear and be careful and reserved.

As I do believe alcohol is a solution to many problems, one of my short term goals is to hop on a plane with some of the other team members and just go have a beer with the two out-of-state guys. Maybe it'll work or maybe I'll be posting a different answer on SE in the future.

The bottom line is do whatever you can to improve communications:

  • Try to get people to socialize in non-work setting (i.e. what I already said above)
  • Promote pair programming or at least collaboration whenever it makes sense. I know some will balk at the idea of always being tied to another developer so this may not be for everyone.
  • Co-location, if possible, definitely helps but is it always possible?
  • As S.Lott pointed out, stand-ups will definitely promote team communications
  • Random check ins -- sometimes even in daily stand-ups people will report their task is going "fine", but when you just pop into their cube, you might find out they are stuck on something for the last 3 hours.
  • Invest in better communications software. We have instant messaging and I still feel even that makes people too detached. We've been throwing around ideas of giving everyone web cams.
  • Informal, no management, meetings to talk about what's on peoples minds. How they feel the project is going, where are you lacking, potential problem areas to watch out for. This is kind of like Agile retrospective, but at least the way we've been doing those, it seems it is too formal and often people are told to stop talking because there's an agenda. While that type of meeting helps to move things forward and we do make progress in terms of retrospective, it seems to squash some of the desire to communicate.
  • Lastly, code reviews definitely help and you should introduce them and ensure that they are done regularly. They are another communications point for your team. However, you will recognize many similar problems in code reviews that you see now. A lot of times, there would be a better solution but by the time code review rolls around it's already been coded and you don't feel like making people rework what was done. Would be nice to get them to talk before they go down some path in the first place.
Improve this answer
0

If you do them, sharing time estimate with the team can help. I am not really talking about "timeboxing" either. Rather, I will tell one of my minions that I think a task should take X hours/days. If they start on the task, and realize they are not making enough progress as they approach X, then they know that they need to reach out. The flip side of this is that you need to do the same thing for yourself, which demonstrates to the team that you are meeting your goals and helps reinforce that you are estimating accurately and can offer sound advice for tackling a problem.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.