The laziness of synchronous work
blog.vivekhaldar.com
blog.vivekhaldar.com
Coworkers who bug you without looking stuff up themselves may be enabled by open-plan layouts, but they're really a different issue.
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...
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?
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.
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.
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.
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.)
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.
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.
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.
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?"
Personally I'm big fan of rubber duck debugging and narrow communication channels.
Perhaps one of those PMs that never gives you all the facts or gets hazy when you ask about completely obvious future roadblock to your work (with the inevitable, 'I'll think about that and email it to you', which of course never comes) so that you constantly have to ask them questions so they feel indispensable when in fact the're just terrible at communication.
And of course they're too busy to explain it all to you because everyone needs their questions answered and if they don't run off now the whole project will fall apart without their wise guidance.
You might want to sugar coat that for your mate, but he's probably just a shit PM. People don't want to constantly be asking what they should do next, it's incredibly annoying and embarrassingly immature for professionals to be having to hang on to a PM's meagre titbits like a baby on a teat just so he can feel indispensable.
OTOH, that could all just be quite obvious transference from a terrible PM I once knew...
Today? I rarely encounter a problem that I can't solve, or at least get good direction on solving, with a few web searches. Figuring things out for yourself just really isn't that time consuming anymore... why ask your co-workers when you can ask the whole world and instantly find the best answers.
Edit: maybe this "mom and pop" shop is using an arcane homegrown framework for their web projects? OK then I could see that it makes more sense to ask the people who understand it. Or it might make even more sense to use one of the standard frameworks.
Regarding the framework they use - They started with oscommerce, but rewritten it so heavily part by part over the years that I don't suspect there's anything of it left (which is a good thing by my count).