I was in meetings most of this last week at work. Meanwhile, one of my co-workers was learning a new style of programming--and thus was trying to learn about four big new things at once. She sent me emails, but I was slow to answer; I was in meetings. Days passed; she could read documentation, she was a quick study, she was learning a lot... but wasn't learning the things that would help her, you know, get started doing stuff. Before you know how to get started, you're not sure which things to study to get you started. On Friday afternoon, I sat with this one co-worker. I didn't tell her much--but I steered her at what she needed to get started. Soon afterwards, she was set up with her development environment, had a "hello world" going, was ready to apply some of that stuff she'd read about. Such a difference. Face time speeds things up. Except, of course, that it won't help the next person who wants to learn those four big new things.

How do computer programmers learn? Though it pains this professional tech writer to say it--they don't learn much from documentation. There's gossip, but that only gets you so far. There are so many different kinds of things to learn: general tradecraft, programming languages, project-specific knowledge... The project-specific stuff is especially tough to learn, because you're probably rewriting your project's code all of the time, pulling the rug out from under your own feet. In Knowledge Sharing in Software Development the author, Jan Chong, studied two teams of developers organized in two different styles to watch how job-knowledge flowed within each group.

(Yes, puzzle huntists, that Jan Chong. No, I probably wouldn't have heard about it if she wasn't a puzzle huntist.)

One of the groups followed the Extreme Programming cult, the others were Waterfa-- Hey, come back! This is not a Book on $foo about how $foo is better than the Waterfall strawman.

This book is Jane Goodall among the Geeks. Except that the author is a geek herself, and understands what's going on a lot better than Jane Goodall understands chimps. So when she took notes, she didn't say "Vocalizes technical knowledge, wish I could understand it." She said, "Desire to project technical competence." Oh yeah, how many times have you been stuck in that conversation.

The book doesn't start out seeming useful. It starts out in full-on academic mode. No sentence escapes without citing a couple of sources.

"Work has changed significantly over the past fifty years, moving from a workforce predominantly based on manual labor to one that is increasingly based on knowledge work (Drucker 1993; Elliasson 1996)."

It's not just that, as an academic, one has to cite sources to back up a statement like that. It's that one has to state a statement like that in the first place or risk getting questioned on it by some professor type who doesn't even know what it's like to work for a living these days. Halfway down page 2 of this, I nearly gave up. But I riffled ahead and saw

The Waterfall programmers also invited me to several team-wide social events in the course of observations, including periodic board and card game nights (e.g., playing Robo Rally, Chez Geek, Guillotine)...

Well that was more accessible. And I couldn't help but notice that the list of games didn't say "Robo Rally (Garfield, 1994), Chez Geek (Darbro, 1999), Guillotine (Peterson, 1998)" So, OK, first few pages have plenty of citations to remind the committee that a sufficiency of past reading has gone into the work. But you don't really need to slog through much of that to get to the real work. And there's good stuff in here.

The book describes the behavior of two groups of programmers. One group is a team of Extreme Programmers--they pair-program, forming new pairs each day, all sitting in one big work area where everybody can hear everybody. One group is a team Waterfall programmers, each sitting in an office with a door, where every bit of intra-team communication requires effort. The book looks a lot at the social networks that formed. But that's not what I focused on.

I focused on this snippet about the XP programmers:

...the practice of pair programming made visible the process of reasoning inherent in code construction, a process normally only available through post hoc accounts and code inspection. Through pair programming, the process was made available in situ.

They developed code faster because they all looked at the same code. They rotated between areas of the code. No one was the "datastore expert" or the "security expert" or the whatever expert--they all wrestled with all parts from time to time. They didn't need to comment or document their code so much--because they could talk it over with each other.

They produced code with little documentation. Like most code, it didn't make much sense--but if one of them didn't understand it, they could always ask someone else on the team. Then again, if someone who wasn't on the team didn't understand it... that person would have been out of luck. The XP programmers were happy to be oral, because they didn't need to slow down to explain things. But heaven help you if you wanted to understand their code and you weren't on the team. The XP team checked email once a day; didn't answer their phones. They spent time with the team, no distractions... from, say, the people who were stuck maintaining the code the XP programmers had previously developed.

...on the XP team, specific program code changes were actually quite opaque outside of a given pair.

Yeah, I bet.

So... the good news is that the XP team developed code very quickly by working all day, ignoring the outside world, and not trying to make their code understandable outside of the team. The bad news is that they ended up with some semi-understandable code. By working in pairs, they made sure their knowledge was distributed between their brains but that also made them less likely to capture their knowledge where someone else could read it.

Of course, most of the time that the Waterfall team puts into recording knowledge is wasted. You re-write code so many times over the course of a project, it's a waste of time to explain how any of it works--until you're ready to share it with somebody else. They track so much crap, most of which won't help future maintainers.

What would be the best of both worlds? How do you get the team to work together well, but make sure that they explain their work before they hand it over to the outside world? You almost want to set up an XP team--and then geographically split them up in the last few weeks of the project, force them to clarify things, nudge them to capture the knowledge that they use to clarify the code to each other. Just remember: that explanation you emailed to your co-worker probably also makes a dandy code comment. And the very fact that one co-worker needed that email suggests that patch of code isn't as self-explanatory as you hoped.

(Yes, training-minded co-workers, I have this book at my desk and you can borrow it.)

Last weekend, I did some programming. Well, not much programming. Mostly I did research preparatory to programming. Well, not exactly research. It was more un-research.

I started out learning how to use the OAuth protcol to... to do something it's not meant to do. OAuth is useful, but I learned that it wasn't meant to do what I wanted. If lots of people worked hard, you could use it for what I wanted--but that would be silly, because you can use OpenID for what I wanted.

What I wanted was to set up a little web app with user accounts that didn't ask users for a password. Instead, it would ask the user if they already had an account at some service: Yahoo, Google, Twitter, Flickr, or whatever... and then ask that service: hey, is this person who she says she is?

What I wanted was OpenID, which does that. (Like, say, this OpenID consumer sample implementation for AppEngine.)

But I'd heard some third-hand news a while back. Chatter on forums: Don't use OpenID. None of the big services are using OpenID. Folks asked Google to use OpenID, but Google didn't--because it's insecure. Google's pushing for OAuth instead, and they're web security smarties, you should use OAuth.

That was wrong. I'm not sure how much of the wrongness came from me mis-interpreting what I heard. I'm not sure how much of the wrongness came from the ignorance of the folks spouting off in the forums. But there was plenty of wrongness.

I'm pretty sure I'm not the only one who got confused. Some guy wrote a blog post just to say that OpenID and OAuth are not the same thing.

So I spent a while studying OAuth, thinking "This is kind of a bass-ackwards way to do what I want." Until I finally decided to look over OpenID some more.

The rumors of Google's rejection of OpenID are false. I can write a little web app. That little web app can (if you have a Google account and you give your consent) ask Google: is this person who she says she is? And Google will answer. The Google security team will not jump out from behind your refrigerator and break your fingers.

There are so many technologies to learn. You don't have time to learn them all. How do you find out which things are worth learning about? Me, I listen to chatter. I don't think I'm the only one. It's embarrassing to think about but... for all that we're supposed to be rigorous engineers, we fall back on gossip to figure out what to study in depth. What worthwhile things do we ignore? What do we ignore because of some unearned sneering comment on some IRC channel somewhere that's been repeated, relayed, never fact-checked...

Sorry, was I ranting? I do that.

I recently read an article by London Times writer Alan Brien in which he wrote

"I used to think that I was the first reader, enraged by the difficulty of tracking down a passage in a long work of reference without re-scanning every single page, who proposed that all non-fictional [sic] books without indexes should be denied copyright."

"Indexes–pleasures of; pitfalls in; regrettable absences of; penalty for failing to provide"
Feb 23 1968 London Times

I encountered this quote as I hunted for an article by Mr Brien--an article I might have found right away if only the publishers of the Times had seen fit to provide an index.

To be clear, though this passage pissed me off when I first encountered it, I don't think Brien was being hypocritical. I think he was being humble. I guess he didn't expect that anyone would go through the Arts sections of decades-old newspaper microfiches looking for his old articles. Manual indexing takes effort. It almost seems an act of hubris to create an index of one's own writing.

(It's times like this when I love my job.)

It's a collection of essays on Computer Science by Tony Hoare, dating from the 1960s through the 1980s. This isn't what you'd expect to find on my reading list, but the essay on Communicating Sequential Processes comes up when you study up on concurrency, e.g., in that Rob Pike lecture lecture on concurrency in Newsqueak. And that essay did explain some strange vocabulary in Erlang, vocabulary like "guards". Where did this jargon come from? From Hoare, probably. Wow, there he is talking about it in this essay right there. It's enough to make the hair on the back of your neck stand on end.

It's good to read essays by the giants of computing. Things change quickly in this field. This means that you can ignore the historical points that you disagree with, while holding up those you do agree with as "timeless truths of eternal verity." I agree with this one, so I'm going to use it to win arguments:

...we admitted that it was the duty of programmers to educate their managers and other departments of the company by "...presenting the necessary information in a simple palatable form." The hope "...that deficiencies in original program specifications could be made up by the skill of a technical writing department... was misguided; the design of a program and the design of its specification must be undertaken in parallel by the same person, and they must interact with each other. A lack of clarity in the specification is one of the surest signs of a deficiency in the program it describes, and the two faults must be removed simultaneously before the project is embarked upon." I wish I had followed this advice in 1963; I wish we would all follow it today.

"The Emperor's Old Clothes"

I skipped most of the book, though. Most of the essays in this book are about proving program correctness. Oh man.

Look, I appreciate that the people who try to prove program correctness are very clever. It's just... it's just... if I'm supposed to learn your notation, and then follow your five-page line of reasoning... if I'm supposed to convince myself that each of these steps is correct, that you haven't made any mistakes (and I'm not sure that I'm clever enough to spot these mistakes; but I do know that cleverer people than you have made mistakes in these proofs...) It's just... it's just that...

Rather than spending the time on a proof, I'd probably be more reassured that your algorithm is correct if you give me a hand-wavy explanation, a demo, and pointed at a few unit tests. I'm just sayin' is all.

The SF Minigame was awesome. But I can't say much about that now, since other folks will still get a chance to play in that game. So... a book review about Don't Make me Think

This is a book about web usability. Suppose you're creating a web site. You worked really hard to get this thing working. Ideally, people needn't work hard to use your web site, to find their way around. But all too often, that's how it turns out.

This book is about web usability. It's about setting up web sites so that people can figure out how to use them.

I don't design web sites. I just, you know, write stuff. I'm a technical writer. But there is some overlap. You can write a brilliant essay about, uhm, designing a database schema--but no-one will ever find that essay if you don't help them. And if you decide to divvy up that long essay, divvy it up into a few smaller web pages, that can help people to read it unless you screw up and people can't figure out how they're supposed to navigate between those pages.

I didn't learn much from this book, but it was still worth reading--it's short! And I did learn some things. One of these things was pretty important:

When someone's scanning a page, hoping for a link to something interesting, they of course won't read the whole page. They're scanning. If they notice something halfway plausible, they click it. If you have a few subtly-different choices, make sure they're right next to each other. If you have a link to your Pasta FAQ and links to your Spaghetti FAQ, most folks will just click on whichever of those they find first.

I guess I kinda knew that. I knew that my Pasta FAQ should have a notice close to the top saying If you have a Spaghetti Question, you want the Spaghetti FAQ and a similar "mercy link" at the top of the Spaghetti FAQ. But I wasn't thinking so much about how to structure a page that had links to both FAQs. So now I have more to think about.

And if I hadn't already had all too many conversations about usability, I probably would have learned even more from this book.

Unfortunately, it's not so clear how to apply his Usability-Lab on the cheap advice for technical writing. I can see asking an engineer, "Here's a pile of documentation. Does this tell you enough to write an international currency computer? OK if I sit over here and watch you struggle?"... but I don't think it would go over so well.

Another problem with reading a book about web usability is that I keep switching over to bold-face text for a sentence or phrase for no apparent reason. Sorry. I'll try to stop that.

A while back--long enough ago that I'm probably getting details wrong--someone told me how the Scoobies tackle a puzzle. They set the puzzle out where everyone in the team can look at it. They look at it. But instead of everyone blurting out their ideas at once, they just kind of keep them in mind. After a while, they go around and folks talk about hypotheses. The intent: share some hypotheses, resist the temptation to go haring off after the first dang fool notion to pop into someone's head. Our brains do that--someone says "Hey maybe it's Morse code?" and, bam, everyone looks at that puzzle through the lens of Morse code. It's hard to break out of that Morse-ish point of view even when you've intellectually convinced yourself that it couldn't be Morse code, no way. It's as if someone said "Don't think of an elephant."

The technique is that someone says "Maybe it's Morse code," but before everyone looks back at the puzzle someone else says, "...or maybe, gee, I think it's semaphore", then your brains are less likely to get stuck in the Morse code track/trap. Everyone pipes up with their ideas before looking back at the puzzle.

So I was mighty interested when Ducky Sherwood mentioned a similar computer-debugging technique in her blog.

If you aren't a computer programmer, you might be surprised to find out that debugging a program is like solving a puzzle. It's a stretch, but... If you're looking at a puzzle, you're staring at something like, say the seeming nonsense 208120'19 238120 1985 19194; you're thinking There's a bazillion possibilities about what message is encoded here; there's a bazillion possibilities about how it could be encoded; how do I narrow down the possibilities? How do I test ideas? When you're programming, you're thinking In this web shopping-cart program, I expected taxRate to be .08, but instead it's 0.2; there's a bazillion places where we could have accidentally clobbered that value or skipped setting it; how do I track down exactly where things went wrong?

Ducky had read that programmers tend to fall into mental traps. Why does taxRate have the wrong value? It must be a memory corruption bug! You've run into a couple of memory corruption bugs lately, and you're soooo sure this must be another one. So you waste a couple of hours running the program under a heavy-duty memory-corruption-bug-finding tool. Meanwhile, you totally ignore the fact that this shopping cart belongs to your first-ever customer from Puerto Rico and your database of local tax rates has the wrong value for Puerto Rico.

Ducky decided on a new approach to debugging: before diving into the code, make up three hypotheses about what the problem is.

... After a binge of reading Andrew Ko papers last week, I decided to start forcing myself to write down three hypotheses every time I had to make a guess as to why something happened.

In my next substantive coding session, there were four bugs that I worked on. For two of them, I thought of two hypotheses quickly, but then was stumped for a moment as to what I could put for a third… so I put something highly unlikely. In once case, for example, I hypothesized a bug in code that I hadn’t touched in weeks.

Guess what? In both of those cases, it was the “far-fetched” hypothesis that turned out to be true! For example, there was a bug in the code that I hadn’t touched in weeks: I had not updated it to match some code that I’d recently refactored. ...

--"false hypotheses"

Those papers she mentions--Ducky researches programmer productivity. She's not just making up this three-hypotheses approach out of thin air. She's basing it on some research, though apparently the research itself is not so easy to find, as she points out in a later blog post:

I finally got my hands on the dead-trees (i.e. uncorrupted) version of the Klahr/Dunbar article that I posted about earlier, and it didn’t say anywhere how long people in the hypothesizing group spent on coming up with hypotheses. However, I was able to track down David Klahr, and emailed to ask him how long they hypothesizing group spent hypothesizing. He graciously and quickly replied that it was only a few minutes. So if we make a wild guess that “a few” works out to an average of about four minutes, then the hypothesizing group took an average of about 10.2 minutes, while the non-hypothesizing group took an average of 19.4 minutes — so the hypothesizing group is still twice as fast as the non-hypothesizing group. ...

--"Hypothesizing first makes you more productive"

So there's support for this notion of coming up with a few hypotheses before trying one of them out. And notice that this research mentions groups of people, not just lone programmers. Teams of people... hmm...

The important world-saving question here is of course: How to apply this to team-based puzzle-solving games? How do you convince folks to not blurt out their ideas in the first 30 seconds? This activity attracts plenty of competitive people. If I look at a puzzle and yell out "I think it's Morse code!" before anyone else on my team does... and if the puzzle is Morse code, then I get to strut as we walk back to the van, right? I just proved I'm a puzzling stud, right?

Or maybe I was the first to blurt out Morse because I'm a fan of Morse, I want to see it everywhere, it's always the first thing I look for. If I spotted Morse while my semaphore-loving teammate thought Is it semaphore?... Oh, I guess not maybe that's not cause for strutting. If the puzzle isn't Morse and the whole team wastes half-an-hour barking up the wrong tree, that's no good. It's all very well that I can say "Well, I just spoke up with a theory; other folks could have spoken up with their theories. I didn't gag them or anything." but maybe by speaking up so early, I caught their brains in the Morse trap. Maybe I should have kept quiet, tried applying Morse code for a minute on my own, let my team-mates consider other possibilities.

How long to sit and ponder quietly? How do you decide when to share ideas with the group? If you have three ideas, how do you decide which to work on first? I don't know.

Now that I think back, I vaguely remember that the reason I heard about this technique is that Alexandra Dixon wanted us Mystic Fish to use it--she had us look at a puzzle quietly, then share hypotheses. But I think that when we looked at the next puzzle, we were back to our blurty ways. (Or maybe the next puzzle was such a stumper such that no-one had any good ideas and everyone had kept quiet out of ignorance, not out of technique? So then when we saw the next-next puzzle, we had forgotten why we'd kept quiet before?.... Oh, vague vague memory.) So this technique does take discipline; it doesn't seem to come naturally, at least not to Team Mystic Fish, and I haven't seen other teams do it, either.

It was six months when I started looking for work and it was just this last week that I got my first phone screen. There aren't many technical writing jobs in San Francisco, thus phone screens are rare. So I was pretty excited: finally, a chance to eliminate my commute!

Partway through the phone screen, I was trying to convince this company's CTO that he didn't want a technical writer. I don't think I convinced him. I probably wasn't very coherent--I was pretty surprised when I realized "Hey what the heck I am trying to talk this guy out of hiring me!?!" But I couldn't help it; when I talked with him about the project, it sounded like he could get a lot more use out of a short-term contractor writer and a junior programmer. And I said that before I really thought I was disqualifying myself.

And thus I will continue with my long commute.

My job title is "Technical Writer." But that's not my mission. My mission is:

Spread knowledge

Writing technical documents is one way to spread knowledge; sometimes it's the most appropriate way; often, it's not. Sometimes I get so wrapped up in some document that I forget to stick my head up, remember the big picture.

The Social Life of Information is a book about the big picture of spreading knowledge. It was written back in 2000--back when the internet's firehose of information was about to wash away all conventional governments, businesses, economies, societies, and we were all going to live happily ever after. The book points out: new communications technology eases the flow of information around the world, but there's still a "last 5mm" problem--getting that information through a learner's skull.

Lately, I've been working on company-internal documentation. I work for a large multi-national corporation with clusters of software engineers hacking away across the globe. Some group in Dublin figures out a clever way to do something useful. Can we spread that knowledge to other groups? Maybe. Sometimes.

The Social Life of Information touches on many topics. But my current focus caused me to latch onto certain parts. The second half of this book could have been called How Organizations Learn. I kept hitting passages which made me nod my head and say "Right on." Please indulge me as a quote long passages from this book.

...The instability that rapidly-changing technology brings, however, often lies less in the technology itself than in enthusiastic expectations that everything being "just a click away" or "at your fingertips" will make life easy. Battered by such hype, it's easy to believe that everyone except you knows how to use this stuff without a problem.

We saw this pressure at work on a new employee at Xerox PARC. She was intelligent and hard-working, but got mired in difficulties with the office computer system. That system came with the usual promises of "usability" and self-explanatoriness, but she found it impossible to use or understand. Being a newcomer, she was reluctant to keep asking for help. ...

Then chance moved her desk from an isolated office into the center of a group of offices. There she immediately benefitted from... incidental learning... She saw that these "stable" machines crashed for everyone. She saw that there was no more "ease" for experienced assistants, long-time employees, or PARC's hallowed computer scientists than for her. And she also saw that when a machine did crash, its user would without shame look around for help from someone else who, whatever their status, had successfully steered around that particular problem. No one person knew how to handle these temperamental machines. But spread around the office was enough collective knowledge to keep them up and running.

This story makes me cringe. She didn't report these crashes to the people who could fix them? Surely, there should be a way to report the crashes--along with documentation of "known problems"-- a-and with workarounds for those problems! Surely we should solve this problem with tons and tons of documentation. Then I calm down a bit. It takes effort to document things, to maintain that documentation. How much time should she have put into trying to track down where each crash was coming from, coming up with a good report? Who would be in charge of tracking the known problems? That takes effort, too. When you hire someone for some random job, you don't tack "...and must write excellent bug reports" onto their job requirements. It would be nice if these people carefully tracked down every defect, but it's not a realistic hope.

[When Alexander Graham Bell was promoting use of the then-new telephone]... The company needed, Bell argued, to abandon specialists and specialist training and put the phones in people's hands. In the right circumstances, the practicality of the device would do the rest. So he crafted the circumstances. ... [The company] put phones near lunch counters. That way, it reasoned, people who didn't know how to use them would be likely to see people who did know how and in this way learn about the phone system.

Later, they mention that one thing that helps people learn how to drive motor vehicles: before they learn how to drive, they've probably been a passenger many times, watching someone else drive. It's almost an apprenticeship system.

Another interesting section...

An anthropologist, Orr, studied the Xerox technical representatives (reps) who service and repair the company's copiers at customers' sites. ...

The company tried to provide the reps with the targeted information they would need. [It provided training and documentation.] ...

Everyone knew what reps did. But Orr argues forcefully that work is rarely well understood. Neither management nor management theorists, he points out, are adequately "concerned with work practice," by which he means they "do not focus on what is done in accomplishing a given job." He was not surprised, then, to find out that what looked quite clear and simple from above was much more opaque and confusing on the ground. Tasks were no longer so straightforward, and machines, despite their elegant circuit diagrams and diagnostic procedures, exhibited quite incoherent behaviors. Consequently, the information and training provided to the reps was inadequate for all but the most routine tasks they faced. ...

The reps' real difficulties arose, however, not simply because the documentation had lapses. They arose more problematically because it told them what to do, but not why. ... So when machines did something unpredicted, reps found themselves not just off the map, but there without a compass or tools for bushwhacking. ...

Orr begins his account of the reps' day not where the company process begins--9 o'clock at the first call--but at breakfast beforehand. From a conventional perspective, the reps' job was highly individual. Routine work was carried out alone... Yet Orr found that the reps were remarkably social, getting together on their own time for breakfast, lunch, coffee, or at the end of the day--and sometimes for all of the above.

...At these meetings, while eating, playing cribbage, and engaging in what might seem like idle gossip, the reps talked work, and talked it continuously. They posed questions, raised problems, offered solutions, constructed answers, and discussed changes in their work, the machines, or customer relations. In this way... they kept one another up to date with what they knew, what they learned, and what they did.

If I really want to spread knowledge around my company, should I write another document? Or should I offer to take care of an engineer's pet budgie for a week, freeing that engineer to travel to a remote site and sit down to lunch with a different group of people?

Reps tell stories about unsolved problems in an attempt to generate a coherent account of what the problem is and how to solve it. They may do this individually, putting their own story together. Or they can do it collectively, as they draw on the collective wisdom and experience of the group. ...

While it may appear at first that the reps used stories to circulate information, they were actually doing much more. For it is not shared stories or shared information so much as shared interpretation that binds people together. In their storytelling, the resps developed a common framework that allowed them to interpret the information that they received in a common light. To collaborate around shared information you first have to develop a shared framework for interepretation. ...

Before you can describe your day to someone, you need to understand your day and that someone needs to understand your vocabulary of description.

As a result of Orr's work, rather than trying to support the reps with yet more information from outside the reps' community, Xerox instead turned to reinforcing internal ties. The first step was simple. Reps were given two-way radios, which allowed them to continue to talk to one another even when working apart. This intervention both supported and acknowledged the reps' ways of collaboration, narration, and improvisation.

The second step was more ambitious, but it too reflected the resources the reps provided for themselves and tried to amplify this resourcefulness. Though passed on in war stories, the insight reps developed in the course of their work tended to have a short reach, traveling primarily in local groups, and a short life, fading from memory even locally. Consequently, reps near and far ended up reinventing fixes that might have been known elsewhere. The Eureka project set out to create a database of this useful knowledge, preserving over time and delivering over space resourceful ideas.

I.e., rather than giving them the effort of a writer, it was more useful to give them a tool that made it easy to record knowledge themselves. Maybe your organization needs a scruffy wiki more than it needs another polished document.

...To maintain a competitive edge, firms first search for the best practices either within their own or in their competitors' units. Once identified, they then transfer these to areas where practices are less good. The search part has led to a a great deal of useful benchmarking. The transfer part, however, has proved much more awkward. ... the now-famous lament of HP's chairman Lew Platt, as he considered how much better the firm would be "if only we knew what we know at HP."

Spreading knowledge ain't easy. Some moves, but a lot of it slips between the cracks.

Another colleague, Jack Whalen, showed the power of practice in his study of learning in a service center taking the calls from customers and scheduling technicians. ...the people who take the calls can save the company money by diagnosing simple problems and telling the customer how to fix these for themselves. ...

The phone operators are not, of course, trained as technicians. In the past, however, they learned from the reps when the latter called in to pick up their next job. The reps would then explain how trivial the last one had been, and in the process the phone operators could learn a lot from these mentors. When they next took such a call, they could offer such a solution. ...technicians no longer pick up calls this way. Consequently, operators no longer pick up insights. ...

The company has tried to replace this kind of learning with the more explicit support of a "case-based expert system." ... This alternative has not worked well. As the reps found with "directive documentation," it can be surprisingly difficult to get a clear diagnosis and solution this way. Moreover, such a system doesn't help the operators understand what they're doing. ... the company contemplated new training courses...

Whalen and his fellow researchers took a slightly different route, however. They studied one service center and the quality of diagnosis its staff provided. There they found two operators who gave especially reliable answers. One, unsurprisingly, was an eight-year veteran of the service center with some college experience and a survivor from the days when reps served as mentors. The other, however, was someone with only a high-school diploma. She had been on the job barely four months.

The researchers noticed however, that the newcomer had a desk opposite he veteran. There she could hear the veteran talking calls, asking questions, and giving advice. And she began to do the same. She had also noticed that he had acquired a variety of pamphlets and manuals, so she began to build up her own stock. Moreover, when she didn't understand the answers the veteran gave, she asked him to show her what he meant, using the service center's own copier.

...Ultimately, Whalen concluded, given the amount and level of knowledge already available in the room, what the operators needed were not so much expert systems or new training courses but "longer phone cords." (These allow an operator taking a call to slide over to the desk and the screen of a resourceful colleague who could provide the necessary help.)

Documentation wasn't useless in that story. The veteran had pamphlets and manuals. But the documentation wasn't enough, couldn't stand on its own.

We see two types of work-related networks that, with the boundaries they inevitably create, are critical for understanding learning, work, and the movement of knowledge. First, there are the networks that link people to others whom they may never get to know but who work on similar practices. We call these "networks of practice." Second, there are more tight-knit groups formed, again through practice, by people working together on the same or similar tasks. These are what, following Lave and Wenger, we call "communities of practice." ...

Great, new buzzwords with which I can bewilder my colleagues. Maybe if I say "network of practice" enough times, I'll irritate my co-workers enough such that I can trick them into reading the book just to find out what I'm talking about.

...In a similar vein, Saxenian draws attention to the importance of social forces to the development of Silicon Valley that both encourages and is encouraged by the networks of practice that run between companies. By contrast, the companies of Route 128 discouraged fraternization between firms. This insularity not only cut firms off from their ecology but also prevented the ecology as a whole from developing. ...

Promoting internal communication is good; don't forget to pull in people from the outside, though. I work for a big, growing, company. I could talk to a different brillant co-worker every day and never run out. If I did that, it would be tempting to forget the many brilliant people outside the company that I wasn't talking to. It's easy to fall into the trap of provincialism.

Gee, I'm tempted to just type the whole book into this blog entry, but my fingers are getting tired and that would probably violate copyright, so I'll stop here. I'll just recommend that you read this book. But not on this blog post. Oh, poor tired fingers.

Is your team playing in the upcoming Back to Basics/Midnight Madness game on April 5? Would you let me play with your team and then write about it afterwards? If so, please get in touch with me (web+comment@lahosken.san-francisco.ca.us).

A couple of years back, Continental Breakfast let me tag along as they play-tested the Hogwarts Game, and I wrote about it. And thus the world got to find out that: Continental Breakfast has an unusually high concentration of Australians. See, that's deep reporting.

The world needs to learn startling facts like this about your team. No, really, other gamers are curious about you.

Questions that people have asked me about this "embedded-reporter" project:

• "When you're reporting, do you play the Game? Or do you just sit in the van and take notes?" I play. I tone down my style at first until I see how the team works together. I'm interested in how the team works together, and I try not to Heisenbergishly change that. But that doesn't mean I'm going to keep quiet when I notice some paragraph of puzzle text contains an unusually high density of hyphens and periods.
• "What kinds of teams do you want to report on? Top-scoring? Most veteran? Snappiest dressers?" Any and all. Eventually, I'd like to do this for a variety of teams. So I guess if I end up writing about too many in some, uhm, category then I'd want to make an effort to write about other kinds of teams for a while. If I'm only writing about one team per year, I bet it will be a while before that's an issue.

If that sounds like something that your team could stand, I am web+comment@lahosken.san-francisco.ca.us.

You think I read this book because of my recent hospital visit, but I swear it was already on my to-do list. And it's not just about medicine. Sort of.

This book, by Atul Gawande, is sort of about medicine, but if you work on anything where quality is important, you'll probably see some things that echo with your experience. Doctors have a tough job. They face many problems, some of which have no solutions. It's not always easy to tell if what you're doing is helping or hurting--if you try some procedure, you'll always wonder if things might have worked themselves out on their own. And yet they do feel their way towards solutions. This book talks about maintaining hygiene; about medicine in a public hospital in India; about measuring your own performance; about stranger things.

I want to check the book Ambient Findability out of the UC Berkeley library. So I looked it up in the catalog:

1.     Morville, Peter.
       Ambient findability / Peter Morville.
       Sebastopol, Calif. ; Farnham : O'Reilly, 2005.

Moffitt      QA76.9.D26.M67 2005
               MISSING

Stir craziness > geek craziness.

I got a new computer today. I was really excited! But not for the reason you think. Sure, it's a sweet new machine that actually works with my DSL connection, so I no longer have to worry about my dialup going away. But that wasn't the exciting thing. The exciting thing was I'd been waiting around the apartment all day for the courier to deliver this machine. So once I'd received it, I didn't unpack it from the boxes. Instead, I got the hell out of my apartment and went for a walk around the neighborhood. But of course the first thing I did once I got home was unwrap this machine etc etc and now here I am typing on it. So the geek force within me is strong.

I warn you: only computer programmers want to read The Algorithm Design Manual. But they might like it. I liked it.

It's something like a Computer Science 101 textbook and yet I'm glad I read it. It starts out like you'd expect a textbook to. But then chapter 8 comes along. Chapter 8 is a laundry list of computer science problem types with a list of different ways of tackling them. It's kind of like the "Have you tried...?" lists for puzzle hunt nOObs. First your figure out the general class of problem that you're dealing with. Then it has a list of questions to ask yourself about the problem--Is there a logical way to order the data? Are the regions likely to fall in clusters? Sometimes the answer to a question then leads to a way to tackle the problem. Sometimes, answering the question just helps you to understand the problem better. I had quibbles with the way it tries to classify computer science problems, but trying to organize all of computer science into a hierarchy is probably impossible anyhow; no harm done.

You might remember a while back I read the book RE/Search Pranks 2 and found out about Julia Solis, who together with the organization Dark Passage set up a LARP based around New York and an abandoned subway tunnel. She also does a lot of urban spelunking. The book New York Underground is her ode to the tunnels beneath New York city. There are historically-researched anecdotes. Some of the anecdotes about train tunnels sounded familiar to me. This suggests that there aren't so many of these stories floating around; maybe if I'd read other books about New York's underground tunnels, these stories would all be old.

But I really like the photographs. Are the underground tunnels really lit up like that, or did she need to sneak lighting equipment down with her? The spooky green illumination of the cyclotron on Columbia University campus... But it's not just the lighting. There are the smooth lines of the tunnels, the broken debris on the tunnel floors, graffiti left by trespassers for trespassers. Go read this. Or at least look at the photos.

Oh, cool! Raymond Chen posted a comment about rebusrally. At least I guess it was Raymond Chen. Maybe it was just some other Swedish/English speaker, and they wanted to mess with my head.

This book is about how Microsoft set up a research lab in Beijing. This was a pioneering effort. China's economy had opportunities for kids who wanted to Make Money Fast in computing--but not so much for kids who wanted to do basic research. Microsoft came in, set up a lab, set up a sounds-weird-to-me-but-apparently-normal-in-China program where Microsoft Research could issue their own academic degrees. If you think you might want to read about something like that, this book is pretty interesting. If you would cross the street to avoid reading about something like that... uhm, this book won't win you over. I thought it was pretty interesting.

Early Saturday morning, my friend Tom Lester drove me to the Emeryville Amtrak station from Berkeley. He pointed out the bakery called Sweet Adeline, and said that they had good cookies. My memories of the next 33 hours are kind of hazy. There was a train ride. Then there was about 20 hours sitting in a hotel room in Sacramento, watching people answer phones, answering a phone, and getting progressively twitchier if five minutes passed without hearing a phone ring. Then there was a party. Then there was another train ride, and I was back in Emeryville. Then I was in Berkeley, on a pleasantly cool Sunday afternoon, at Sweet Adeline, eating ginger snaps and drinking cold milk. It seemed to me that this was the best snack I had ever had in my entire life, but you might not want to trust that thought, though--my judgement was pretty impaired by that point.

But you can trust this book report. I wrote it ahead of time, before the weekend, back when I could still think straight:

I read the compilation The Best American Essays 2005. I picked it up because it contained the essay "The Sea of Information" by Andrea Barrett. She writes books that are weighty with historical research. Surely, I hoped, an essay by her about "The Sea of Information" would shed insight into her research methods, perhaps give hints about how certain search-oriented companies could help her to research/write novels better faster stronger.

But it turns out that her research methods are not so search-y, but are more browse-y. She's not looking for particular facts. She follows chains of books and ideas. One leads to the next.

About halfway through the essay, you realize that she's answering the cliche question: "Where do you get your ideas?" She reads an old pamphlet about tuberculosis treatment; she looks at photos of an old sugar factory; she looks for quirks of language, the hints they give of another time's way of thinking.

She got a fellowship to work at the New York Public Library. She had an office. She could request more books, someone would bring more books. She read. She read more. One day into her stint in the fellowship at the New York Public Library was 9/11 2001.

Why was I reading all this? Why do all this work, especially when I wasn't writing and didn't know if, when I started again, I'd find a way to use any of it? And especially when I might more usefully have been out in the world, helping someone, fixing something: cleaning up the rubble or raising money or aiding the families of the dead. Instead I read, which is what I do.

This was not the essay I expected to read. It was darker, more gnarly. And though I didn't find the answers I wanted, I did find out how Andrea Barrett gets her ideas. It ain't easy. I don't think I can help her.

Tags: books | belles lettres | library |

In honor of Wondercon (which I'm not attending (yes, I am lame)), a comic book review:

How often do you finish reading a comic book and think, "I wish there was a bibliography."? Arthur Cravan was a dada artist (except, of course, that there was no art, there was only dada). He lived under a variety of assumed names. He boxed. He moved around. This comic book, out recently from Dark Horse, is a biography. According to this comic, Cravan was also an art thief, a smuggler, a brawler, and perhaps wrote the Treasure of the Sierra Madre.

How much of this should I believe? How can I learn more? I tried searching the UC Berkeley library catalog, and found one Cravan biography--in French. The only French I know is tourist stuff, so I won't be able to understand that biography except when it talks about train timetables. I read an interview between V. Vale and some zinester named Dean living in Prague who wrote about Cravan. That has fewer details, but has some reading recommendations:

It's hard to find information in English on Cravan, although he's described quite well in Robert Motherwell's The Dadaist Painters and Poets. The best description, by the art critic Roger Conover, is in Four Dada Suicides.

I guess I need to read more books.

Tags: comics | dada | research |

I am sick today. I lost my voice. So it's a bad day for conversation. But a good day for napping, blogging, and reading. Out of sympathy for my plight, I think you should read Metropolis.

Go read this novel by Elizabeth Gaffney right now.

It's a romance. It's a heist/caper. It's a gangland saga. It's a musical (without the music).

There's a museum of freaks, beasts, and oddities--on fire, including a tiger tiger burning bright. There's a secret tunnel in the sewers. There are canes decorated with silver monkey heads. There's an unwanted pregancy which was obviously tossed into the book as an ill-disguised excuse to show off the author's research into birth-control options in 1870s New York--and it's so interesting that you don't mind. There is a character with the last name "Undertoe".

Go. Get. Read. Now.

Tags: book | Gangs of New York | hygiene |