
The laziness of synchronous work - gandalfgeek
http://blog.vivekhaldar.com/post/54192213683/the-laziness-of-synchronous-work
======
majormajor
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.

------
mordae
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...

------
andrewljohnson
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.

------
unclebucknasty
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
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
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.

------
teyc
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
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
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?"

~~~
scotty79
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.

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

