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.
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...
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.
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?
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.)
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.
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.
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.
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.
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.
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.
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.
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?"
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.
I can see that this sort of thing used to be true. Before StackOverflow, before Google, before the widespread use of the internet... yeah you could pretty easily get stuck on something for hours or days. If you were lucky enough to have usenet you could post on the relevant newsgroups and maybe get some help after a while.
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.
Except that they are often stuck on his company's domain knowledge. That's not something they can google. I know, he should have better docs. Shouldn't we all?
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).
Sounds like a serious problem with his initial direction more than a problem with the programmers, especially if they're all 'try[ing] to figure out things for themselves'.
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...
He's not a PM. Just a developer, admin and entrepreneur. Although recently he delegated all his dev tasks to other people. He found pretty decent people too. At least one of them turned out to be pretty good PM, all decent programmers. All in all he's doing fine. He had to fire just one graphic designer and one marketer because they tended to watch too much youtube at work while still having things to do and one of his programmers quit because he didn't want to work 8h per day at the office. He still does about half of his work for my friend remotely as a freelancer. Growth of his company is pretty impressive. Recently he had to swap offices because he outgrew his old one.
Coworkers who bug you without looking stuff up themselves may be enabled by open-plan layouts, but they're really a different issue.