4 ms·

Yeah, I wonder about the impact on overall team productivity when programmers ask each other questions even when they've drilled down further themselves. Even i

Yeah, I wonder about the impact on overall team productivity when programmers ask each other questions even when they've drilled down further themselves. Even if the programmer who is asked is not annoyed and has more information with which to offer an answer, she must still stop what she's doing and shift gears to offer assistance. This obviously harms her own productivity. Funny part is, the more experienced and familiar with the code base a developer is, the more likely she is to be productive. But, she's also more likely to be interrupted with greater frequency because everyone knows she's the goto. Does the team's overall productivity go up or down in this scenario?

count 13y ago
I think it depends on the junior dev - if they 'learn' when they get their question answered, the productivity of the team over time most likely increases quite a bit; it's an 'investment' in future productivity. If they ask and don't 'learn', but simply mirror / rote regurgitate what the senior dev said, it's probably disastrous to the team's productivity both then and over time.
- katbyte 13y ago
  I'm currently that senior dev and i welcome any and all questions just for that reason. I'd rather spend 5-10 min helping out/teaching a junior to be a better programmer than for me to review code later that just doesn't make the cut or has some horrible mistake leading to the dev having to spend more time overall fixing it. Not only that, but i find that helping others out generally makes me a better programmer.
- unclebucknasty 13y ago
  Good point. And that desire to learn/understand is something that's hard to teach. Some junior devs just grow dependent and are content to stay where they are. When I was in college, I tutored CS. So, I hung out in the lab a lot and frequently helped people with programming assignments. I would always try to help them arrive at the answer vs. just giving it to them. With some people, this worked very well. They just needed a nudge or a little help framing the solution. But, with others, I could spend literally hours trying to get them there with very little progress. In some cases, I finally had to all but give them the solution and help them code it. Thing is, many of them were OK with this. So, after a time, when certain people asked a question, you kind of knew what you were in for. What surprised me, however, is that in large enterprise settings, you had teammates who were similar. I don't know if you could get away with that in a startup environment, but some enterprises are large enough that they can just "carry" some team members.
calibraxis 13y ago
Yeah, these codebase-gurus are often bottlenecks. I personally think they should invest time on documentation and walkthroughs. They could also answer some questions on the condition that the newly-enlightened person must document the answer. (Kind of like caching.) The problem is that many programmers have little training in effective communication (that is, the skill of somehow transferring/inspiring a mental representation from your mind into someone else's). It's like pulling teeth to get them to document — even if they desperately want to escape being pigeonholed as the only one who understands the crappy legacy system. (Even when job security isn't an issue.)
- unclebucknasty 13y ago
  Yeah, that's true regarding effective communication. And, in addition to that, I think some people actually like being the bottleneck. They want to be known as the go-to. I've definitely seen this in enterprise situations. Not only do they fail to try empowering other devs, they actually purposely hold on to information in order to foster ongoing dependence. Whether it's for job security, ego, or otherwise, it's not an uncommon sight.
rjd 13y ago
I used to work with a guy who did the same thing every time you went and asked him a question while he was in the middle of something. He would answer your question politely and talk you through it etc... but when you got back to your desk he would ALWAYS over and over send you an email link to a Joel Spolsky article stating it took 15 minutes to regain concentration after you are interrupted. His message being wait to I'm not obviously working, try someone else, or spend an extra 15 minutes (x2 devs) yourself trying to get to the bottom of it yourself.

count 13y ago

I think it depends on the junior dev - if they 'learn' when they get their question answered, the productivity of the team over time most likely increases quite a bit; it's an 'investment' in future productivity. If they ask and don't 'learn', but simply mirror / rote regurgitate what the senior dev said, it's probably disastrous to the team's productivity both then and over time.

katbyte 13y ago
I'm currently that senior dev and i welcome any and all questions just for that reason. I'd rather spend 5-10 min helping out/teaching a junior to be a better programmer than for me to review code later that just doesn't make the cut or has some horrible mistake leading to the dev having to spend more time overall fixing it. Not only that, but i find that helping others out generally makes me a better programmer.
unclebucknasty 13y ago
Good point. And that desire to learn/understand is something that's hard to teach. Some junior devs just grow dependent and are content to stay where they are. When I was in college, I tutored CS. So, I hung out in the lab a lot and frequently helped people with programming assignments. I would always try to help them arrive at the answer vs. just giving it to them. With some people, this worked very well. They just needed a nudge or a little help framing the solution. But, with others, I could spend literally hours trying to get them there with very little progress. In some cases, I finally had to all but give them the solution and help them code it. Thing is, many of them were OK with this. So, after a time, when certain people asked a question, you kind of knew what you were in for. What surprised me, however, is that in large enterprise settings, you had teammates who were similar. I don't know if you could get away with that in a startup environment, but some enterprises are large enough that they can just "carry" some team members.

calibraxis 13y ago

Yeah, these codebase-gurus are often bottlenecks. I personally think they should invest time on documentation and walkthroughs. They could also answer some questions on the condition that the newly-enlightened person must document the answer. (Kind of like caching.) The problem is that many programmers have little training in effective communication (that is, the skill of somehow transferring/inspiring a mental representation from your mind into someone else's). It's like pulling teeth to get them to document — even if they desperately want to escape being pigeonholed as the only one who understands the crappy legacy system. (Even when job security isn't an issue.)

unclebucknasty 13y ago
Yeah, that's true regarding effective communication. And, in addition to that, I think some people actually like being the bottleneck. They want to be known as the go-to. I've definitely seen this in enterprise situations. Not only do they fail to try empowering other devs, they actually purposely hold on to information in order to foster ongoing dependence. Whether it's for job security, ego, or otherwise, it's not an uncommon sight.

rjd 13y ago

I used to work with a guy who did the same thing every time you went and asked him a question while he was in the middle of something. He would answer your question politely and talk you through it etc... but when you got back to your desk he would ALWAYS over and over send you an email link to a Joel Spolsky article stating it took 15 minutes to regain concentration after you are interrupted. His message being wait to I'm not obviously working, try someone else, or spend an extra 15 minutes (x2 devs) yourself trying to get to the bottom of it yourself.