4 ms·

I'm a good example of that. I've been in software for about 12 years now and am only just getting started in the mentoring/training type roles. And that's only

I'm a good example of that. I've been in software for about 12 years now and am only just getting started in the mentoring/training type roles. And that's only because I super had to... How do you deal with someone who gets to a problem and cant figure it out and then just drops it without telling anyone or saying anything, and you dont figure it out for days or weeks?

itronitron 8y ago
You'll want to find out what they are stuck on and help or show them how to remove the initial impediment (they might be waiting on someone else or having trouble breaking down the problem into smaller workable chunks.)
- nostrebored 8y ago
  Exactly. Not all technical mentoring is about software engineering; many of the problems junior employees face are regarding soft skills that they need to get their job done. While you might understand what to do if you're blocked internally, or if you're waiting on third party software, or if you get feedback that you don't understand on a code review, these are - new - problems to a lot of people getting started in the workplace, that many try and fail to solve on their own.
prawks 8y ago
> you dont figure it out for days or weeks? If it was important and estimates on how long it will take are overrun, then don't wait to follow up on it and find out how it's going. Unless the problem is more nuanced like a small component of a larger body of work? Like knowingly leaving flaws in an implementation, or something.
duxup 8y ago
That sounds like a manager type situation if you have devs just not doing things and not telling anyone, rather than mentoring.... that's pretty terrible.
pm90 8y ago
You usually set up a system where you have constant feedback, like daily stand ups, weekly ( or bi-weekly) sprints etc. before closing out an issue have the devs demo the feature so it’s not based purely on word of mouth. Personally: I would advice getting lunch with them and getting to know them better. Set up a 1:1 if lunch isn’t possible. Everyone likes honest feedback, or at least a chance to talk about their difficulties in getting tasks done.
wpietri 8y ago
This sounds too simple, but you just don't let people go days without checking in. I wrote about once simple process here: http://williampietri.com/writing/2014/simple-planning-for-startups/ http://williampietri.com/writing/2014/simple-planning-for-st... The key points to keep things on the rails: 1) it's a work queue for the whole team, and the whole team is responsible for every work item, 2) the units of work are small, so they should generally be finished in a day or two, and 3) you to quick daily checkins to make sure work is moving along. If you add pair programming with frequent pair rotation (e.g., 2-3x/day) then you make it impossible for a person to get stuck for long periods. Even if two people are stuck for a couple of hours, when pair rotation happens then the pair can ask somebody with specific experience to tag in.

itronitron 8y ago

You'll want to find out what they are stuck on and help or show them how to remove the initial impediment (they might be waiting on someone else or having trouble breaking down the problem into smaller workable chunks.)

nostrebored 8y ago
Exactly. Not all technical mentoring is about software engineering; many of the problems junior employees face are regarding soft skills that they need to get their job done. While you might understand what to do if you're blocked internally, or if you're waiting on third party software, or if you get feedback that you don't understand on a code review, these are - new - problems to a lot of people getting started in the workplace, that many try and fail to solve on their own.

prawks 8y ago

> you dont figure it out for days or weeks? If it was important and estimates on how long it will take are overrun, then don't wait to follow up on it and find out how it's going. Unless the problem is more nuanced like a small component of a larger body of work? Like knowingly leaving flaws in an implementation, or something.

duxup 8y ago

That sounds like a manager type situation if you have devs just not doing things and not telling anyone, rather than mentoring.... that's pretty terrible.

pm90 8y ago

You usually set up a system where you have constant feedback, like daily stand ups, weekly ( or bi-weekly) sprints etc. before closing out an issue have the devs demo the feature so it’s not based purely on word of mouth. Personally: I would advice getting lunch with them and getting to know them better. Set up a 1:1 if lunch isn’t possible. Everyone likes honest feedback, or at least a chance to talk about their difficulties in getting tasks done.

wpietri 8y ago

This sounds too simple, but you just don't let people go days without checking in. I wrote about once simple process here: http://williampietri.com/writing/2014/simple-planning-for-startups/ http://williampietri.com/writing/2014/simple-planning-for-st... The key points to keep things on the rails: 1) it's a work queue for the whole team, and the whole team is responsible for every work item, 2) the units of work are small, so they should generally be finished in a day or two, and 3) you to quick daily checkins to make sure work is moving along. If you add pair programming with frequent pair rotation (e.g., 2-3x/day) then you make it impossible for a person to get stuck for long periods. Even if two people are stuck for a couple of hours, when pair rotation happens then the pair can ask somebody with specific experience to tag in.