Advocacy, guruship, and the multi-disciplinary Web professional

By Ben Henick, 6 January 2014

A few days ago, Jeff Croft delurked (one might say) to point out that mastery of HTML and CSS alone is an obsolescent skillset, itself a state of affairs for which we have web standards advocacy to thank.

My immediate reaction is that this is not news, that for fifteen of the sixteen years I’ve been in this trade, I’ve been building on the markup and Photoshop post-production skills that I developed in the beginning. The goal has been—and remains—to be “the guy”: need a website? I can build it!

Jeff is correct when he calls web standards advocacy a victim of its own success, and when he exhorts us to diversify or die.

Jeffrey Zeldman, meanwhile, underscores the fact that web standards advocacy was always meant to be a victim of its own success, that its goal was to free up developer time for Good Ideas that, in 1998, we were wasting on bad implementations.

Forest, trees…

Both of these articles conflate begin by implying that a generalist skillset with often signifies failure to achieve complete mastery of any platform in the web stack other than HTML and CSS, and completely ignore at first give short shrift to two facts:

Another point that gets a rise out of me—enough so, in fact, to write this when I should be packing for an imminent interstate move—is the daily overemphasis on tools that I see. JavaScript is a tool, as is every framework ever written in JavaScript. Git is a tool, as is every other source control platform ever built. PHP is a tool, as is every other server scripting language in regular use. The list goes on, but my point is that the tools rarely speak for the underlying knowledge and skill: it’s all well and good if I’m conversant with JavaScript, but what I (and you) must be able to do is implement an application that doesn’t explode the instant it’s glanced upon crosseyed. One hopes, actually, that it would be implemented with even more skill than that.

I make good generalists seem near-godlike, perhaps; if that is true, it’s because generalists assume responsibility for more knowledge, and are likely quicker studies at the left end of the learning curve, than their specialist teammates. It’s also likely that a generalist sees black magic where a specialist sees a perfectly reasonable algorithm or architecture, and thus needs to step back… to learn more, right then and there.

…But more than a defense.

When I read that {x} is dead (long live {x}), I suffer the impulse to attack that sentiment. I’m also the guy who, in a vaguely once-notable setting, once implied that the only truly obsolete thing is a dull razor. It’s not the tool; it’s what you can do with it.

Adulthood (actually, middle age approaching far more rapidly than I’d like) convinces me that too many people—and especially too many of us—try to apply technological or process-oriented solutions where only human solutions will do, and our approach to building sites is no different.

Let me supply a metaphorical example:

It’s early springtime on the west slope of Mt. Hood, and one of the suddenly-Arctic storms for which the Cascades and Sierras are famous (cf. the Donner Party) happens upon me and my companions. None of us can get a cellphone signal. Between us we’re more or less appopriately-dressed for an overnight in typical conditions, but the odds are short that we’d start walking in circles due to the prevailing blizzard conditions, were we to attempt a walk back to the timberline.

What training teaches us in that situation is to shelter in place… and we have trenching tools, which aren’t ideal but will at least allow us to dig shelters.

Every sitebuilding team has its trenching tools: members with hidden skills, useful process shortcuts, hidden caches of experience that illuminate creative (and perhaps even MacGyver-esque) solutions to vexing problems.

However…

Too many teams are assembled like a WoW party: we need an {a}, a {b}, and a {c}. The hiring manager will typically give some attention to team fit, but still looks to fill slots without much thought to the inevitable snafus. When those arise, someone with sufficient authority always comes along and gives the inevitable order to get it done in a death march—too often after hobbling the project by being unavailable for signoff on a request for resources.

…And you wonder why so many sites suck out loud? Really?! Compressed timelines obliterate any and all slack for effective communication between team members, and that’s the least of the team’s problems at that point. Unfortunately, because the hiring emphasis was directed towards über-specialists, nobody else can step in to supplant the work of a weeded teammate, especially if the op in question is weeded because he was the missing piece that the hiring manager waited interminably to hire. Because a specific toolset is required in your shop (hi, Drupal!), better-suited tools were disregarded completely, which is no small part of how you got into the timeline-compression mess in the first place.

It’s the product, stupid.

So goes the fury that makes me want to go on the attack. No sitebuilder worth a damn should focus exclusively upon just one small stack, and no manager with half a brain should rely on such a person to build a product.

The guru knows this… and is overlooked, because precious few believe that he or she can demonstrate the skills claimed, because the guru is more interested in building things than in taking credit for building them.

The allure of the rock-star might be shiny, but it kills the promising potential of too many projects… and perhaps it will eventually kill somebody working on one of those projects.

I wait and I wonder… and I learn.