Man Bites Blog

alastair has a post taking on Jeff Atwood of Coding Horror, and Atwood replies.

Alastair challenges Atwood’s place as an authority on coding, and cites some bold statements Atwood has made on his blog .  Atwood responds that he never claimed to be an authority, and that his bold statements are an example of the SmackDown method of learning, and his desire to hold strong opinions weakly.

The problem is that, for a blogger like Atwood, with thousands of RSS subscribers and daily page views, there is no such thing as holding an opinion weakly (to ape Atwood’s typical style of putting his own opinions in boldface), or at least of expressing an opinion weakly.  A blog post that reaches thousands of readers is by definition strongly holding an opinion strongly.  It inhibits, rather than encourages discussion.

To take an extreme example the Bush Administration couldn’t claim that it was just throwing out the idea that Saddam has WMD as some sort of academic exercise to test their theory and prompt discussion.

In the blogosphere, there is a bit of a conflation between popularity and expertise (ahem), and we forget that what makes a blog popular is completely different from what makes a writer authoritative, particularly in niche fields like programming.    Dennis Forbes makes a good point in a comment on alistair’s post:

It really is irrelevant whether Jeff feels himself an authority figure or not (it is debatable either way). What really matters is whether the community, or a loud enough subsection of it, sets him up as an authority figure.

Exactly.  If, “but Jeff Atwood says PHP sucks” is seen as a winning argument, then it matters what Atwood writes on his blog. 

In essence Atwood’s blog is such a powerful weapon that his initial smackdown ends the fight.  It may be the case that a consensus emerges in the comment thread against Atwood’s original conclusion, and Atwood may even come around to that conclusion, but none of that is featured as prominently as Atwood’s original post.

There’s a fine line between taking a bold stand to provoke discussion and bullying other people with your opinion.  Atwood’s posts often come off as the latter rather than the former.  Perhaps that is all that is possible for a prominent blogger.

Andrew Sullivan writes about the tension between blogging and more permanent writing:

The kind of brain activity that permits one to post two dozen items a day, keep track of countless more, and surf endless online reports and ideas and spats, is not conducive to also producing a long or reflective or deep work of philosophy or fiction or history or poetry. Even if you find the time, your mind cannot adjust that quickly.

A typical IT worker has two activities that compete for his time and attention:

• Troubleshooting/Firefighting
• Design, development of longer term solutions

If you’re familiar with Stephen Covey’s work, you know that the second set is “quadrant 2″ activities, whereas the first bullet point is in quadrant 1 or 3. This presents a few problems.

The problem is that a lot of the things we tell ourselves are in quadrant 1 are really in quadrant 3. The IT and business culture rewards those who lead the troubleshooting/firefighting efforts. Those who continue their design and development while others are firefighting are considered poor team players. The rewards for firefighting are real and immediate. The rewards for development work are not.

On a slightly darker note, a culture where everyone jumps in to help out on the latest fire is a culture where nobody is accountable for their design or development deliverables, because there’s always the excuse of some fire coming up that required their attention, so they “didn’t quite get” to completing the design, and schedules slip.

The other problem is that although these activities require different types of “brain activity,” it is typically the same people who are good at one that are good at the other. In part this is because nobody knows a system like the person who designed it, but it is also because the same skills — analytical ability, focus, and determination — are transferable to both problem areas.

The final problem is that a lot of the effort of deign and development is loading to contextual information in your mind. Once there, you can be “in the zone” and make leaps of progress without what seems to be a large effort. But this requires long blocks of time.

But office life isn’t always geared toward that. Your coworker will ask for help. The department secretary will ask for the serial number from your PC for the third time in a month. Your spouse will call for help in resolving some child care issue. You’ll be reminded to fill out your timesheet. A vendor will call. etc.

Eventually, you get discouraged, and even when there seems to be a block of time, you don’t work on the Quadrant 2 stuff, since you know you’ll only get interrupted. Hello, Quadrant 4!

What to do about it?

Well for one, those who are good at context switching will be very valuable. Those who can jump back and forth between development work and troubleshooting without getting discouraged or dropping the ball are and will continue to be very valuable. I’m not sure if this is a skill that can be developed or a natural talent.

Second, we need to defend the quadrant 2 activities, and sell other stakeholders on the idea that allowing us some time to focus on them is in their best interests. It’s hard for people to understand how disruptive their one little question can be. They don’t realize that they’re one of ten people with one little question.

This can be a hard pill to swallow. Closing yourself in your office while everyone’s running around chasing a problem doesn’t initially seem very “customer-focused.” But it can be the best way to serve them, and prevent future fires.

Finally, it usually takes a little bit of analysis to triage between Quadrant 1 and Quadrant 3 requests. By the time that’s done, the damage for the interruption has already been met, and you may as well go ahead and respond to the request regardless of its importance. Which is why value-added gatekeepers are necessary.