Wednesday, June 1, 2011

It takes a tribe to raise a member

I'm not sure I want to perpetuate the analogy of "tribes" to a work environment, because, going on my career so far, I've rarely seen the necessary level of cohesion extend beyond, say, three co-workers.

But Best Friend H. was chunking out code when I was still struggling to parlay a Liberal Arts degree into a "real job," so I tend to trust her instincts. This past weekend, she used the phrase "tribal knowledge" in the context of griping about why outsourcing projects to contracting firms was capable of so much friction. Friction, I might add, that had nothing to do with time zones or language or even cultural norms.

That concept has been brought home the past few weeks as I've been on the short road to tinnitis, trying to block out days' worth of brain-dumping. And that's just for one application. We're trying not to traumatize the trainee, so I haven't even started loading my dump-truck just yet. (Much less the gleeful rubbing of hands, twirling of moustache, maniacal laughter, etc., etc.)

But in a much more tangible sense, I only need rewind to last Friday. I don't think I'm telling too many proverbial stories out of school when I say that a software enhancement was expected to be rolled out to the production (i.e. live) website this Tuesday, and we still needed to make a final check on the "beta" (i.e. dress rehearsal) server. Quality Assurance (QA) was already slated to test over the weekend, and Alpha-Geek was likewise planning to make the final code-push, assuming it passed muster.

I handle promotions in the afternoon, so the programmer responsible passes the issue off to me. So far the tribal knowledge seems to have trickled down, despite the fact that he's only been with us for a small handful of months.

Except the tribe missed passing on the bit of collective wisdom that says that if your patch is that important, you should probably stick around to see it safely promoted and, oh, maybe even spot-check it before handing it back off to QA. But, being a self-respecting barely-post-collegiate type, he, naturally, made for the door in anticipation of a three-day weekend.

I duly promoted the database portions, then realized that the programmer had forgotten to to merge one chunk of the code into the production branch of the Subversion repository. Hypothetically, this should be only a minimal inconvenience, because I should be able to update my copy of the "production" repository, merge the designated changes from the beta version, and commit them up.

It's an amiable enough hypothesis, to be sure. But it reckons without the fact that, between the time programmer made his change and the time I had to merge them, a directory had been deleted. Which means that Subversion had had its little drama-queen hissy-fit freakout about a tree conflict. In laypeople's terms, this leaves me with three possible options:

A.) Trust my version of the files
B.) Trust the incoming version of the files
C.) Try to negotiate a compromise

Only problem was, I wasn't privy to the "tribal knowledge" behind the "missing" folder and its contents. That had left with the programmer in question--and, for that matter, everybody else. Which left me with two possible options:

A.) Take a wild, flying stab in the dark and let other people shop-vac up any resulting damage
B.) Document what I'd done so far and the problems encountered and foist the rest of the promotion off on Alpha-Geek

Sadly, the latter was the kinder option. (From a passive-aggressive standpoint, it was probably a horse apiece, so I refuse to feel guilty about choosing (B.).) Apart from being copied on the note that Alpha-Geek had ultimately finished the promotion (after working around said freakout), I didn't hear bupkis about the incident after that. I should probably check in to see that the appropriate party was shown the error of his ways.

But the "teachable moment" from all this should, I trust, be the ample demonstration of the value of cultivating knowledge as a tribe. Or, perhaps more aptly, the counter-wisdom of grafting individuals (and even whole teams) onto a project without thoroughly marinating her/him/it in the deep end of the knowledge-pool. The best possible outcome otherwise is gross inefficiency; the worst is wholesale disaster. The foolhardy grafter should expect no sympathy in either case.