If you see any more spam here, please let me know.

In other Spam-related news, I'm learning Python so I can contribute patches to existing software at work, rather than just poke around the edges by writing little Perl scripts here and there. Not that my job officially involves writing software, but sometimes it's the most straightforward path to a solution. I'm about halfway though Learning Python and it's going pretty well so far. I'm taking a break from the book to rewrite one of my aforementioned peripheral scripts, as a learning exercise.

The first article, Wayne Curtis's Weni, Widi, Wiki, told the story of a visit to Seattle using only Internet guides, specifically those with user-generated content. It seemed to highlight for me the reason I'm no longer so interested in Yelp, Amazon Reviews, or most of the crowdsourced Internet. My first thought after reading this article was that I was simply tired of opinions.

Several years ago, I enjoyed being a fire-breathing opinion columnist with the primary mission of thinking provocative thoughts and the secondary mission of generating page views, with only a tertiary mission of being right. If I was wrong in a way that made people stop and think about the problem, I'd won.

I don't think I'd enjoy that job much today. By and large, I just don't care whether people like my opinions, or agree with them. If people ask me what I think, I'm more than happy to share my opinions, but I'm not all that likely to volunteer what I think. (This has made it harder for me to blog, since I feel so reluctant to say anything without prompting.)

Then I read the very next article, Corby Kummer's Beyond the McIntosh, about John Bunker, a man who has dedicated his career to preserving heirloom varieties of apples. At the Capitol Hill farmer's market, I buy most of my apples from one guy, who grows a mix of things people have heard of, and things that most people haven't. I discovered my favorite variety of apple there, and was tickled pink to discover that it's the same as John Bunker's favorite: the Black Oxford, native to Maine, and the apple that launched Mr. Bunker on his career.

If I didn't care about opinions, why would I be so excited by the information that John Bunker's favorite apple was the same as my own?

The answer, I think, is the difference between solo and aggregated opinions. Crowdsourced reviews have the same grey, mushy feel of meals at The Cheesecake Factory. When I first paged through the copy of Zagat's restaurant guide for Seattle I'd been sent, I couldn't believe that people were as likely to praise the Cheesecake Factory as to dis Lark, my favorite Seattle restaurant.

But of course, Zagat's guide polls hundreds or thousands of people (myself included), and averages out their opinions. On average, people will prefer an unchallenging place, with giant portions of bland food, to a restaurant specializing in small plates of often strange or exotic food - and that's true even if each individual's preferences are otherwise.

I suspect that almost everyone who reviewed The Cheesecake Factory has an interesting, even unique, set of food preferences, and that I could talk for a good long while with most of them and find their individual opinions fascinating, even when I disagreed with them. But, taken together, these individual opinions cancel each other out and leave you with an uninflected average opinion.

I remember some science fiction story I read as a teenager, in which one character posited that the Venus of Willendorf represented an averaged-out map of what men desired in women, which puts me in mind of Jason Salavon's work.

In other words, preferences are more interesting individually than when they're aggregated. This is the lesson of Apple versus Microsoft, where the former is a distillation of one man's particular aesthetic and the other is the product of endless usability tests. I'd go so far as to assume that Microsoft's software would be more interesting, and more pleasing to myself, if it were the product of Bill Gates's personal vision, or even that of a single usability research subject. But such software would likely be less successful overall, if we define success as marketplace success, the definition by which The Cheesecake Factory succeeds.

I never pick up my Zagat, and I'm not much more likely to rely on Amazon, Yelp, TripAdvisors, or its myriad crowdsourced descendants. I'd rather go up to a stranger, as my boss did one night in New York City, and ask the name of his favorite bar. In fact, one recommendation was the first bar I ever remember going to in order to see a band, The Continental. I was surprised, and more than a little pleased, to find that they were still there. But most of the recommendations were places I hadn't heard of, or would have found on my own.

Sometimes aggregated opinions are toxic. I had a particularly bad experience when I tried to find reliable information on picking out a Blu-Ray player. HD-DVD partisans had so poisoned the pages on Amazon and other sites that I was unable to tell who had really used the player in question, and who was merely trying to sow uncertainty and push people to HD-DVD instead. Claims and counter-claims proliferated, with no end in sight.

In the end, I bought a low-end Sony player, upgraded the firmware to the latest before trying anything else, and have had not a single one of the myriad reported problems. Was I just lucky, or was all of the concern overblown? The plural of "anecdote" is not "data", even if it's my anecdote. What, exactly, do we call the plural of "opinion?"

Of course, it goes without saying that the future e-Book would be far lighter than the present version, with longer battery life, and more flexible. What does it look like, when it's finally light enough, and cheap enough?

Google could mint them by the millions, with Google AdWords embedded in the margins of every page, and could mail them out to people, like AOL floppy disks, or hand them out in Las Vegas like pornographic come-ons for strip clubs and escort services. They'd be free to use, free to connect to the Internet, and self-funding, so long as the AdWords revenue holds out.

You'd have all your books stored online, like WebMail, with some sort of token-based instant login, so you wouldn't bother to take it with you if you were done. Instead, you might leave it on a bus stop bench, or in a cafe. Someone might want to check e-mail, or read a book, and pick it up, then put it down somewhere else again. And all the time, the ads roll by...

The easiest thing to do is probably to grab the automator workflow from the linked post, and replace the shell script within with the following bits:


#!/bin/bash

done


Last week, I presented at SASAG on this topic. I've made my presentation on Professionalizing Technical Support available here; it's still a PowerPoint document. Please let me know if you'd like this data but require a different format. The extensive notes, of course, represent what I wanted or tried to say, not what I ended up actually saying. (Like any good SAGE meeting, the presentation was much more a discussion than unidirectional transfer of information and ideas.)

Read on for my impression of the meeting.

• People agreed that there existed concerns shared by technical support staff, and seemed to accept the notion that Technical Support was a semi-independent field that might deserve professionalization. (Nobody argued that it was just one part of being a system administrator, for example, even though many system administrators perform technical support.)
• People recognize that Technical Support is the face of IT, and it’s important.
• People accepted the claim I presented (based on a summary of the Jonassen paper referenced in the presentation) that the best predictor of troubleshooting ability is experience; somebody who has spent more time troubleshooting performs better than someone who hasn’t, even if the latter person has more theoretical knowledge.
• People recognize that Technical Support is typically staffed by very junior people, because the job is not widely considered desirable.
• People recognize that the inexperienced people typically on the front lines of technical support damage the reputation of the entire technical organization: they frequently lack the customer management skills that more experienced technicians have developed, and often do an objectively poor job due to a lack of experience.
• People seemed to accept my contention that the best solution would be to make technical support a desirable career; however, people seemed somewhat skeptical that this was achievable.
• Reasons that this wouldn’t be likely revolved around three major points:
  • Money: people can make more money in Sales, Management, and even in Development. This was the most frequently (and vociferously) argued point.
  • Accomplishment: the frequent recurrence of many problems across different customers (or even with the same customer) leads to a sense of futility. Unlike project-oriented work, technical support staff rarely get to stand back, look at a completed piece of software, and say, “I did that.”
  • Predictability: many technical people prefer situations where they can set their own schedules (even if they have to work more), with fewer fire drills and screaming emergencies; technical support offers many fire drills, screaming emergencies, and lots of talking with unhappy people.
• People seemed willing to entertain the notion that somebody, somewhere should work on professionalizing technical support.
• People agreed that mentorship was the primary vehicle for socializing new technical support engineers, and even argued that mentorship was how law students, doctors, system administrators, and other professionals learned their jobs.

There are no strict action items at this time. I’m trying to decide whether it makes sense to try to hold some kind of in-person meeting for technical support professionalization in the Seattle area, if this concept should be presented in person in other contexts (ie, at conferences and other local technical groups), or if it can be successfully pursued online.

Before determining if some sort of group makes sense, I imagine that I’d need to develop some explicit agenda items for that group. Obvious candidates include a forum for presenting and discsussing case studies of how people are performing technical support; case studies of mentorship and training programs; discussing and refining troubleshooting methodologies; and promoting development of technical support as a career rather than as a stepping stone a different career in Sales, Management, or Engineering.

I'm extremely interested in talking to anyone who has ideas, wants to contribute toward moving this forward, or strongly disagrees.

Sad to say, this was a side-grade as much as an upgrade, as we've lost the ability to play music in our living room without turning on our television. The Airport Express can be selected as an output device directly from iTunes on the computer, without requiring any messing around device-side.

For most people, having to turn on the TV to play music is no big deal — it is, after all, called the Apple TV. However, we have a projector in our living room, and the screen pulls down in front of a big glass door to our balcony, so it's normally retracted. Furthermore, in daylight it's tough to see the screen unless we close all of the other blinds in the living room, too. Therefore, to use the Apple TV to play music, we have to close three blinds, pull down the screen, turn on the projector, and wait thirty seconds or so for the projector to be ready. Which means that, right now, it's easier for me to shamble to the other side of the room and dig through seven-hundred-plus CDs to find what I'm looking for.

I hope that a near-term software upgrade for the Apple TV enables the Apple TV as an alternate output device, as one can do with the Airport Express.

[ 2008-04-05: This feature is no longer missing! ]

I'm in tech support, and I love my job: I love helping people solve problems, and I love working on the tricky things. I like working on streamlining processes to reduce support effort, I like figuring out how to communicate internally and document our processes. I even get to do a little bit of writing scripts for internal use and to solve customer problems that, strictly speaking, shouldn't be our problem.

That said, I often feel like I'm making it up. I feel like my management's making it up. And I don't think that's their fault, or mine.

It seems to me that even the biggest players fail to provide adequate tech support, and so when Joel posted Seven steps to remarkable customer service, I nodded my head more than I usually do while looking at blogs.

It sounds like Fog Creek Software solves the problem in a way that only smaller IT shops can; I don't think their techniques could apply directly to life at Dell, or even where I work. But the ideas are important for all tech support shops.

A number of people have done awesome work on professionalizing systems administration; The Practice of System and Network Administration is an example of that. Where's the parallel effort to professionalize tech support?

On a technical level, working on troubleshooting techniques or considering a debugger's-eye view of particular subsystems would make great conference tutorials and presentations. I could certainly use a course on reading SMB packet traces as a means of troubleshooting filesharing issues, or on putting together flowcharts that tier 1 engineers would find useful. (If I'm Mac-less, but have access to Windows and to Linux, is there a better way to do this than Visio? What kinds of notations does experience show are used by Tier 1 folks, and what kinds don't work as well?)

Figuring out how to communicate across shifts in a 24-hour shop with multiple people on each shift, and how to appropriately schedule people, are things that everyone seems to have figured out in their own way. However, a lot of that seems to be "this worked at my last shop, let's try it here" and "it's not great, but I don't have any better ideas." Having people present lessons learned from their own projects or shops might improve results for all parties.

Knowledge bases are another great topic; I'd like to see product comparisons and case studies, from search results to see how these tools get used, how to entice engineers to contribute, article templates that produce different levels of responses, and so on.

I've done my Google searches, and I'm not seeing the conferences, journals, books, or blogs for professionalization of technical support. Given that support is a huge cost center for many businesses, and given that it's difficult to determine best practices for the field, it seems to me that someone should probably do something with regard to this.

I'm happy to give of my copious free time toward results in this arena.

You could do something similar with e-mail on a social networking service: to 100% of my friends, 50% of their friends, and 25% of the friends of the friends of my friends. This could be neat, and less overwhelming than the current setup.

Apple has left out the ability to display the iTunes visualizer when playing music using the remote and Front Row. Why isn't this available, not to mention a sane default?