22 ms·

The laziness of synchronous work

37 points by gandalfgeek 13y ago

unclebucknasty 13y ago
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.
mordae 13y ago
I like the second part. It's spot on. When we were designing our current project, we have spent whole days together, listening to di.fm, drawing on papers, scribbling on whiteboard, thinking, discussing. We managed to stuff completely coherent idea of the architecture into our heads (and into skeleton code) so that even now, after an unwanted 3 month break we can continue writing pieces and know exactly how do put them together. From there on, it's mostly headphones and only infrequently some coordination discussions. Why am I even writing this? It might be that I am just happy about it...
majormajor 13y ago
Here's a fun alternate-alternate universe: you do the digging, hit a wall, and then still have a coworker in the same building who can dig further with you more quickly, once it's convenient for them. Coworkers who bug you without looking stuff up themselves may be enabled by open-plan layouts, but they're really a different issue.
ams6110 13y ago
Isn't this exactly one of the problems that "pair programming" is supposed to help?
andrewljohnson 13y ago
This article is a Rorschach test. Some of us will read it and savor what we see as our powerful, well-oiled work environment, and some of us will look and despair at the unproductive tedium that envelops us. Maybe a bit of each for most.
teyc 13y ago
This article misses the overall value of teamwork and devalues face-to-face communication. Talk to other professions and see if people work this way. Do doctors work on their own if they encounter something they don't know? How about engineers? Lawyers? I'm not advocating disturbing a senior all the time, or for extended periods. However, your search and spelunking through the codebase does not beat random access from the person who knows it. By all means, then take the time to document it, and provide a roadmap for others. Face to face is an opportunity for the senior person to do a running heath check, and make sure your plan makes sense or is consistent with the framework in place. If you recall, BeOS's performance on SMP machines was attributed by Gassee to having the two kernel and gui engineers sitting next to one another. If you are in business, then you are competing with another company. It is no longer university where your personal abilities are tested.
scotty79 13y ago
My friend has small mom & pop e-commerce related web company. He hires over 10 programmers now. The common complaint about his employees I hear from him is that they wait too long to ask about stuff. They try to figure out things for themselves and that's bad because they spend half a day on something that should only take them half an hour if they just asked. He has to ping more stubborn ones periodically to see what they are working on and check if they are not stuck on some banality.
- unclebucknasty 13y ago
  Interesting. Yeah, you know, I think efficiently finding answers on your own is actually a skill, as is knowing when you're stuck and just need a nudge. Probably like most here, I have on both sides. I've been that new, inexperienced guy, dropped in a new environment. I've also been senior guy that others devs depended on. But, I was always very, very conscious of asking others for help. And, you know, with dev you can get into this "almost there" or "one more thing" cycle where you just keep going at it. In that mode, you can easily lose a full day or more. So, it's definitely a thin line. One thing I think that contributes to the challenge is the rise of open-source. On one end, it's been an undeniably awesome (almost unbelievable) movement in terms of what it enables. But, many projects are notorious for being poorly documented and, sometimes, in need of fixes. So, you can get into this mode of hunting sparse documentation, forums, etc. for answers. Likewise, we're probably all more likely to be using a variety of tools and technologies that inter-operate on any given project. Many times, things can get lost in the glue and may be difficult to track down. So, it can be like, "where do I go for help with this particular config?"
  - deleted 13y ago
    [deleted]
  - scotty79 13y ago
    Definitely you can have both extremes when it comes to asking. Same friend, when we worked side by side years ago tended to ask the questions loud even before he asked his own brain. Personally I'm big fan of rubber duck debugging and narrow communication channels.

37 points by gandalfgeek 13y ago

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.

mordae 13y ago

I like the second part. It's spot on. When we were designing our current project, we have spent whole days together, listening to di.fm, drawing on papers, scribbling on whiteboard, thinking, discussing. We managed to stuff completely coherent idea of the architecture into our heads (and into skeleton code) so that even now, after an unwanted 3 month break we can continue writing pieces and know exactly how do put them together. From there on, it's mostly headphones and only infrequently some coordination discussions. Why am I even writing this? It might be that I am just happy about it...

majormajor 13y ago

Here's a fun alternate-alternate universe: you do the digging, hit a wall, and then still have a coworker in the same building who can dig further with you more quickly, once it's convenient for them. Coworkers who bug you without looking stuff up themselves may be enabled by open-plan layouts, but they're really a different issue.

ams6110 13y ago

Isn't this exactly one of the problems that "pair programming" is supposed to help?

andrewljohnson 13y ago

This article is a Rorschach test. Some of us will read it and savor what we see as our powerful, well-oiled work environment, and some of us will look and despair at the unproductive tedium that envelops us. Maybe a bit of each for most.

teyc 13y ago

This article misses the overall value of teamwork and devalues face-to-face communication. Talk to other professions and see if people work this way. Do doctors work on their own if they encounter something they don't know? How about engineers? Lawyers? I'm not advocating disturbing a senior all the time, or for extended periods. However, your search and spelunking through the codebase does not beat random access from the person who knows it. By all means, then take the time to document it, and provide a roadmap for others. Face to face is an opportunity for the senior person to do a running heath check, and make sure your plan makes sense or is consistent with the framework in place. If you recall, BeOS's performance on SMP machines was attributed by Gassee to having the two kernel and gui engineers sitting next to one another. If you are in business, then you are competing with another company. It is no longer university where your personal abilities are tested.

scotty79 13y ago

My friend has small mom & pop e-commerce related web company. He hires over 10 programmers now. The common complaint about his employees I hear from him is that they wait too long to ask about stuff. They try to figure out things for themselves and that's bad because they spend half a day on something that should only take them half an hour if they just asked. He has to ping more stubborn ones periodically to see what they are working on and check if they are not stuck on some banality.

unclebucknasty 13y ago
Interesting. Yeah, you know, I think efficiently finding answers on your own is actually a skill, as is knowing when you're stuck and just need a nudge. Probably like most here, I have on both sides. I've been that new, inexperienced guy, dropped in a new environment. I've also been senior guy that others devs depended on. But, I was always very, very conscious of asking others for help. And, you know, with dev you can get into this "almost there" or "one more thing" cycle where you just keep going at it. In that mode, you can easily lose a full day or more. So, it's definitely a thin line. One thing I think that contributes to the challenge is the rise of open-source. On one end, it's been an undeniably awesome (almost unbelievable) movement in terms of what it enables. But, many projects are notorious for being poorly documented and, sometimes, in need of fixes. So, you can get into this mode of hunting sparse documentation, forums, etc. for answers. Likewise, we're probably all more likely to be using a variety of tools and technologies that inter-operate on any given project. Many times, things can get lost in the glue and may be difficult to track down. So, it can be like, "where do I go for help with this particular config?"
- deleted 13y ago
  [deleted]
- scotty79 13y ago
  Definitely you can have both extremes when it comes to asking. Same friend, when we worked side by side years ago tended to ask the questions loud even before he asked his own brain. Personally I'm big fan of rubber duck debugging and narrow communication channels.