Hey, somebody tell Bay Area Night Game Team White Ninjas that I found the perfect band to play their theme song. It's Leather Feather! Most of the people in the band dress up as white ninjas! (Or else maybe as some characters from THX 1138. But let's say ninjas.)

Let's see if I can figure out how to embed one of their videos:

What's that? You say the team changed its name to the League of Extraordinary Puzzlemen? Uhm... OK. Dang. I don't know any bands for that. Never mind. But Leather Feather is still pretty rockin'.

(Oh, and Holy Fuck is another rockin' band, albeit one whose name doesn't obviously relate to any team that I know of. And 'Shreck played some School of Seven Bells afterwards, and that was pretty good too.)

I work for a large company. Thus, there are "leadership seminars" with "team-building exercises." I attended one of those. I was confessing this to some friends on Saturday, and one of them knew exactly what I meant; he asked, "Were there ropes to climb, among trees?" Yes, yes there were. The ropes didn't teach me much about leadership or people skills or teams. Why not? Because belayed rope-climbing is too similar to belayed rock-climbing. The beginner's lesson of rock climbing which is pertinent to leadership/people/teams is: Once you learn that you can trust your belayer, you make rapid progress by putting your energy into climbing instead of clinging. Thanks to Chuck Groom, I'd already learned that. So the ropes were fun but... Well, I didn't learn much there. For more insights on people, I guess I'll keep talking to them. And reading. E.g., I got around to reading Peopleware.

This book is a classic, by which I mean you've already heard most of what it has to say about managing software development. You've heard it second-hand. Reading the book itself is a little strange. Parts of it make little sense unless you drag up history, let your brain nestle into an old mindset.

Why does the book rail against Productivity? Why does it equate productivity with burnout and overtime? Doesn't improving producitivity mean setting up better tools and processes so that people can work more efficiently? Well... back in the day, "Productivity" meant that folks should work longer hours. Japanese car companies were out-producing American car companies. American executives went to visit Japanese executives and noticed that Japanese office workers stayed in the office long hours. (They didn't notice that Japanese assembly line workers were better trained, were encouraged to improve processes, and... Ahem, anyhow.) They came back and said that we should all work harder. Never mind that those Japanese sararimen weren't getting much done. Thus, Peopleware pointed out that short-term benefits from working long hours were offset by folks burning out--something that seems pretty obvious in hindsight, but perhaps seemed less obvious at the time.

They pointed out that projects that operate without time estimates are the most productive.

They pointed out that programmers need to focus and can do so best in offices with doors that close. They spoke out against distractions. In hindsight, I think they overstated the value of closed offices--over-emphasizing bursts of focused work vs. encouraging folks to talk to each other and exchange ideas--at the time, cubicle-bound programmers were subject to plenty of distractions that weren't useful conversations with coworkers.

They talked about how to prevent folks from having their conversation broken by the telephone. People still used voice communication back then. It was sort of like text-messaging, only... Oh, never mind. You kids today will never understand how rough we had it back then.

They talk about Christopher Alexander, the Design Pattern guy. Back when Design Patterns were architecture architecture instead of software architecture. I wonder if this book is what introduced so many software weenies to design patterns.

They talk about Teams, about complementary skills, about people learning to work with each other. Back in the day, did managers feel like workers were interchangeable? I don't know. There's a bulleted list for team formation.

• Make a cult of quality.
• Provide lots of satisfying closure.
• Build a sense of eliteness.
• Allow and encourage heterogeneity.
• Preserve and protect successful teams.
• Provide strategic but not tactical direction.

These seem like things that most of my managers have tried to do. Like I said, you've probably seen most of what this book has to say, you've picked it up second-hand.

This book is about marketing; about marketing for products which are at a certain stage: they have enthusiastic "early adopters", but no big uptake. This stage sounds familiar to me based on my experience--and apparently it should sound familiar, because it happens a lot. It's so amazing to ship a product, so awesome when you hear that people like it--and then things stall out. Your team works on the next version, polishing your features, waiting for the word-of-mouth to spread... but the word-of-mouth doesn't seem to spread and you start thinking about doing dumb crap like superbowl ads just so that more people will hear about your project because of course if they just hear about it they'll love it like the early adopters did and pick it up too... But that doesn't seem to work out either.

I don't know if the approach espoused in this book works--I haven't tried it. But it sounds reasonable.

You've probably been going after the whole world as your "target market". That's been fine so far. But if you're trying to reach folks beyond the small, enthusiastic fringe of the "early adopters", you want to appear credible. Part of how they decide whether to use your product is--looking around to see if anyone else is using it. You want to aim for 50% of the market so that conservative folks can choose you without finding themselves hanging out with the lunatic fringe. How do you bootstrap your way to that?

Choose a small market. Choose a small market segment with a problem you can solve in a year. You've been trying to solve the world's problems. How about solving the problems of... dental office administrators? If you can tweak your product so that it's the logical choice for dental office administrators, you can probably break into that market. So far the dental office administrators have been struggling along with generic, uhm, calendars that haven't been tweaked to fit their specialized needs. (No optimization for six-month checkups, say.) You'll want to set up comparisons to folks' other choices because folks are more comfy with A/B choices. You're probably going to have to do a bunch of specialized stuff that wasn't part of your original idea. You're probably going to have to think about standards, compatibility... Spread to another small market segment. Another; maybe, like the Macintosh creeping its way out of each company's art department, you can take over the world.

Beware: your company's pioneers, the smart folks who got you this far--they might not enjoy this stuff. Find something else for them to do, pronto. They'll want to keep being disruptive. But the customers you're going after now don't want "disruptive", they want "safe". There are other people-role issues. You'll want someone market-ish to figure out this new market you're muscling in on--someone who can become an expert on dental office administration. This person will spend a year figuring out product stuff, a year during which you won't actually be selling much to the dental folks. Then the sales folks will start selling to the dental admins--and if the marketer did it right, the product will seem to sell itself. But the marketer might have already moved on to develop the next market segment. How do you figure out who did the great stuff--the marketer or the salesfolks? No easy answers; as time goes on, it might be more important to hire folks that work well together than folks who, uhm, accomplish great things on their own.

Further evidence of Darcy's ongoing awesomeness: she rescued the contents of the team Taft on a Raft web site. It's back! Including the material from the The Apprentice Zorg game!

If you sadly took down your taftraft.com links when that old site got taken over by domain vultures and turned into evil webspam, you might want to dust off those links, put them back in, but this time pointing to the new place.

Skott raises an excellent point: The diskworld novels also have golems.

E.g., I read Going Postal. I read this Diskworld novel because it's where the puzzler team "The Smoking GNU" got their name. Aha, it all fits together. The book was nice. It was a fun read. It had golems in it.

I was was avoiding linking to the Muppet Movie Game Site, but have since figured out that was dumb of me. You might say I avoided linking them due to philisophical differences... but really it was mis-placed pre-emptive sour grapes.

I've been around when a couple of the Orange Snoodites talked about philosophy of The Game. I agreed with them most of the way. They said (I'm paraphrasing) The Game is about the experience, not about puzzles. I thought, Right on. If I get to retrieve a puzzle by sticking my hand into a cold cold pumpkinful of spaghetti and finger jello, I think that's pretty darned good. I don't get to experience that working on a crossword puzzle on the bus--they kick you off the bus if you spill mushy pasta and pumpkin innards on your seat. I'm pretty sure they kick you off the bus. I haven't seen a No Pumpkin Innards sign posted on the bus, but I'm pretty sure it's in the regulations somewhere.

The Orange ones said You shouldn't worry so much about your time or your score. I thought, Right on. So much of your team's performance is out of your control; if you agonize over it, you'll make yourself miserable. Different teams approach The Game in a different spirit; comparing your "performance" to theirs might not make sense. (I'll let you decide whether my attitude here reflects my lack of puzzling skills, dot product some more sour grapes.) If your team finishes before RadiKS does but RadiKS gets cooler team photos along the way, then who has won? Two years from now when you're flipping through your photos and only have a blurry snap of the crowd scene at the after party, you'll know that RadiKS won after all.

But then the Snoodists said (again, I paraphrase) Back in the day, we didn't have all of this "application" stuff. There was a Captains List. When you wanted to run a game, you contacted the people on the Captains List and you invited them to play. And I thought, Aw $&#*, screw these jerks. They'd run games years ago. I.e., before I started playing. Who was on their mysterious "Captains List"? Probably a bunch of veteran teams. Probably not any team I could sneak onto. Grr. I didn't like this piece of philosophy, not one bit.

When I heard that the Snoodies were going to run a The Game, I figured there was no chance I'd get to play. I'd blown my opportunity. When I'd talked with them, why had I wasted time nudging them for details on The Overnightmare Game when I should have been sucking up to them, weaseling my way into their good graces?

But my attitude towards this game-application philosophy changed during Ghost Patrol. Specifically, it changed when [this text removed by request of a reader]. So maybe The Orange Snood gaming philosophy is perfect after all. (Not like the Olympic games. $&#*, those jerks never let me play.)

(And it was fun hanging out with O.S. for the Scrabble runaround clue in No More Secrets.)

Now that I figure we have a glimmer of hope of getting in to this game, I'm letting myself read their blog. They're keeping a blog as they plan the game. They've blogged a little about their philosophy, and might do more of that. They haven't said how they'll handle the admissions process. I hope you get in.

Alexandra Dixon, Team Mystic Fish's captain, mentioned how well she gets along with Red Byer of Team Orange Snood. I'd got my history wrong--I'd thought that Alexandra had barely started playing back around the time that the various Orange Snoodites had stopped running games. But there was more overlap than that. So if there was a Captains List, maybe Alexandra was on it after all

On game day, I mostly watched over the Zombie Chess Clue. Most of the time there was nobody there. Some of the time, there were plenty of people there and they kept me pretty busy. But a couple of times, there were people there but I still made time to SNAP photos. After I was done at my post, I wandered down to Addison Street to take photos of poetry lovers so dedicated to their love of the arts that they stood out in the rain to... uhm, yeah, sorry they weather wasn't better for that one. Anyhow, you can see the photos.

If you approach BANG like baseball and want to construct statistics for your team, I transcribed data from the station checklists, team answer sheets, and the results sheet. I'm not sure how much sense my notation makes, but I'm too sleepy to try to explain it now. Maybe you can figure it out and come up with brilliant reports like: typical range of puzzle-solving duration for each puzzle (and number of teams solving), excluding hint-taking teams:

37 -  58 (22)
20 -  31 (24)
20 -  39 (23)
13 -  21 (21)
10 -  20 (25)
39 -  61  (7)
 8 -  15 (23)
78 - 150  (6)

Not excluding the hint-taking teams:

40 -  66 (26)
20 -  33 (26)
21 -  39 (26)
14 -  25 (26)
10 -  20 (25)
58 -  78 (24)
 8 -  16 (24)
88 - 140 (13)

Transcription errors are possible and/or likely.

Joe sent in a zip archive full of puzzles from the game. They are at http://lahosken.san-francisco.ca.us/anecdotal/hunt/25/puzzles/. The Zombie Chess clue isn't in there because we can't figure out how to upload plastic zombies. And/or because I'm too sleepy to snap photos of a zombie chessboard. Maybe some other day. After I catch up on sleep. (My friends Ray and Nhi got married, yay! The reception on Sunday night went way past my bedtime! I am barely keeping my eyes open as I type tihszzzzzzzz....)

Rich Bragg of Blood and Bones sent me some mail about turning BANG 18 into a drinking game, vis a vis a strategy to avoid being obliged to run a future BANG.

...By the way, re: your blog post, while we know it significantly lowers our chances, we don't actually play not to win when we drink after each clue. You know I've always said that winning is fun, but it turns out solving puzzles while drunk is also fun. And in fact, one day we aspire to do both at the same time, and will happily take on the responsibility of running another BANG when it lands on us. :)

...Also as evidence to my claim, the first time we played in this manner was in coed's leisurely mini-game, where there was no threat/promise of having to/getting to run a subsequent event.

Rich (and the rest of Blood & Bones, from what I know) have shown themselves to be honorable in the past, so I'm inclined to believe him. Of course, this raises an interesting question. If you were running a Bay Area Night Game and you wanted to maximize the chance of a drunk team winning, what activities would you choose?

I'm thinking....

• Stereogram. I've never solved one of these, but I understand that you need to unfocus.
• Physical challenge: Walk a crooked line.
• ...

Oh, I'm out of ideas.

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.

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.

The lovely Just Passing Through put together a fun & educational event last night: a GC Summit. Folks who had run Games and/or were considering running Games showed up to eat, talk, and watch informative lectures. Should we call it GC Summit 2008, seeing as how the previous one was GC Summit 2007? Sure, let's say that.

I bet that excellent videos of the lectures will appear on YouTube soon, thanks to Curtis (and maybe thanks to others... Curtis was working the camera... anyhow...). But the conversations before and after were good, too. Unfortunately, I didn't bring along my little audio recorder, so all I've got is a few snippets that lodged in my unreliable-narrator brain.

• On the car ride over, an idea batted around: open-source software that people write for Games. Not just the little web-crawlers and such. But the software that GC writes to track teams' progress, handle pre-game... more complicated things. This idea came up a couple of times during the Summit itself.
• It is now public knowledge that Greg et al. are thinking of a game in early November, but They have not committed, good grief people calm down.
• Casey Jade Holman, age 1.5-ish, has learned to say "puzzle." And she kind of chuckles when she says it. I mean, she says other stuff, too. I don't want you to think that she's growing up warped or something. I'm just pointing out that she seems to like saying the word "puzzle," is all.
• John Owens' good news is that he got tenure. John Owens' bad news is that he didn't receive an invitation to the "Back to Basics" game. G.C. sent physical invitations by post; so you were much more likely to get an invite if GC knew your address. Teams that did receive an invite received two, so they could pass one along to another deserving team. No-one passed one to John. When he said this, I thought back to when Alexandra said that Team Mystic Fish had an extra invite: I had just naturally thought Which less-connected team needs our help? Which of them could we pass that to? Saying "Should we ask Advil if they want an invitation?" is kind of like saying "I hear that the King of Sweden is coming to San Francisco; I wonder if he has a place to stay; should we call up and offer him a spot on the couch?" But if everyone thinks that way, then the King of Sweden ends up... I don't know where I'm going with that simile. But the upshot is... So Team Advil won't play; John will play with the Scoobies.
• DeeAnn talked about how to choose locations for The Game: not too long a drive between locations, but the drive should be at least ten minutes. Why ten minutes? DeeAnn explained: There should be enough time for a player to eat half a sandwich. If you pop into the car, unwrap your sandwich, and then boom you have to get back out of the car again, then you're stuck re-wrapping your sandwich and you're grumpy. Rich Bragg, hale and hearty, had doubts: Half a sandwich...so that's like 30 seconds, right? Brent Holman suggested packing many teeny-tiny bite-sized sandwiches. Perhaps Gaming scientists will one day discover the sandwich molecule, the smallest possible particle one can point at and say "that's a sandwich". Once we know how long it takes to eat that, we will know the minimum possible distance between Game locations. Or we could stick with the 10-minute drive rule of thumb. Whatever works.
• During the after-lecture conversation, Jan Chong's voice was kind of quiet. When two people started talking at once, if Jan was one of them, her voice go drowned out. It made me glad that she presented.
• A couple of newbies showed up, yay! And somehow we didn't scare them too much. Alexandra recruited them for her Leisurely Stroll team. (Or recruited them for something.)
• On the car ride back, one of the people in the car was the one who had, during Q&A after a lecture, asked Seattle teams taking up space in SF Bay Area Games, but not hosting Games themselves. Other folks in the car took issue with this--Seattle doesn't have a monopoly on freeloading teams. If there's a group to kvetch about, it's teams that play plenty but don't host. I don't think anyone convinced anyone else of anything.

While I'm thinking about it... in terms of where to put an "open source" set of Game-ish programs. Some wiki-ish place to put files might be enough, might not need to set up an open-source project. As Jan points out, each GC is probably going to want to tweak enough behavior such that they might want to read old code, but might want to drastically re-write it. I think Yahoo! Groups has a place to dump files, but only readable by people in the group, so maybe not good to use that.

Traffic was bad this evening; my commute was long; I emerged from the bus nauseous. That happens when the commute goes too long: stare at the laptop screen too long while on a moving vehicle, don't look up. My inner ear decides it's going to have one of its moods. I'm stumbling homeward dizzy and grumpy.

Then Yar says "Hey", because, as it turns out, I am walking in front of Yar's house, that is to say the house of a couple of people in Coed Astronomy, a Game team that's running a game soon. So we exchange a few pleasantries.

Then as I kept walking home, I didn't think about the icky bus ride anymore. I thought about

• The San Francisco Bay Area Afternoon Game or whatever they decide to call it
• Shinteki Decathlon 4
• The mysterious upcoming Game

...and I was happy again. Yar, harbinger of joy, reminded me that I have good things to look forward to. (Well, at least one good thing. I'm only registered in one of these games. But you get the idea.)

Tomorrow is Buy Nothing Day, but I'll probably buy some food. Usually, I Buy Nothing for Buy Nothing Day. To make that work, I stock up on food ahead of time. I was going to do that late Wednesday night, but I was sick then. I guess I could have picked up some leftovers from Thanksgiving dinner just now, but I didn't think of it. So I'll buy some food tomorrow. I guess I can make myself feel like less of a consumer whore if I share this book report on a book I got from the library, Dreaming in Code.

It's a book about software projects and where they bog down. Scott Rosenberg hung out with the Chandler Project for a few years and watched them stagger towards creating a working piece of software. He also talks plenty about software projects in general. I get the impression that this book is supposed to be accessible to the layman, sort of a "Soul of the New Machine" for the aughts. I can't tell whether it succeeds--I've been soaking in this stuff for too long to figure out what does or does not make sense to outsiders. But there's plenty in this book that rings true. I've worked with teams who argued about which approach to take--and argued about it longer than it would have taken them to code up both versions and measure which was faster. (On the other hand, you also worry about programmers who just jump in and spend a week coding using some approach which they would have known couldn't possibly work if only they'd talked with someone about it for five minutes.) Anyhow, reading about another project that bogged down... oh, it was kind of sad. Maybe it's a good thing for folks to read when they wonder why the IRS/FAA/etc can't replace its antiquated software.

The best part of this book was a cameo by Ducky Sherwood. Ducky was an intern at my place of employment after the events described in this book. I talked with her at an ice cream social and she was pretty cool. Since she was an intern I didn't think to ask her about her past--all too many interns can only answer "Well, I've been in school, you know?" (Kinda like when I made the mistake of attending my 5th year high school reunion.) But Ducky's actually worked on plenty of projects. Peeking at her web page now, I see that she's working on her MS in computer science, specializing in... programmer productivity. Hmm, maybe she got tired of working on projects that bogged down.

Maybe you've already watched the videos of the GC Summit 2007 presentations, where folks talked about how they make The Game fun. I'm sure glad I watched it. I'm a Game newbie and it was pretty eye-opening to realize how much the Game has changed just in the last few years. Anyhow, if you were going to watch those videos, you probably already have.

You probably haven't read the transcript of some of the hatter that happened before the summit. You probably haven't read it because I just now got around to finishing typing it up. But you can read it now if you're into that sort of thing. Mostly, it was some folks talking about Overnightmare. Hey, it's not much, but it's all I've got.

The team name "Coed Astronomy" of course invokes memories of "SETEC Astronomy," the mysterious code name from the movie "Sneakers."

In the movie, "SETEC Astronomy" turns out to be an anagram for "Too many secrets". So it made sense that "Coed Astronomy" would turn out to be an acronym for something.

And once I finally tried anagramming it, of course it turned out to work out nicely to "TOO MANY CODERS". Wow, how long has that been staring me in the face?

Then again, there are other anagrams that could fit. "ODE TO ACRONYMS". "CRY, O TEAM SNOOD". "SODOMY ON RECTA". Uhm, eww. I think I'm going to stop looking for more anagrams now.

Yesterday, we of Team Mystic Fish got our collective act together long enough to figure out the time & location of the start of the The Apprentice Zorg game. This was, of course, a puzzle. Or, rather it was 12 mini-puzzles plus one meta-puzzle.

This puzzle is disguised as a list of teams participating in the game. That is not a coincidence. Game Control asked each time to submit a "team photo", a piece of media to represent their team. 12 teams were asked to encode a Game-Control-supplied message into their medium.

So if you look at that page, click on the "team photos" that are bordered in red. Each of them contains a secret message. When you have the solutions to (most of) those puzzles, you can apply those to the green-bordered puzzle. (For the red-bordered puzzles, you can ignore the text on the right half of the Teams page--it's not part of the puzzle.)

My personal favorite of these puzzles is Team Briny Deep's; it made me laugh. Usually audio puzzles make me groan. If I told you why this puzzle made me laugh, you wouldn't think it was funny. You need to listen to the puzzle, form a hypothesis as to its encoding, listen closely, think your method is working, think your method is failing--and then realize your method is working after all, but only seemed to be failing because of a joke. And then this feeling of joy and relief washes over you and you laugh uncontrollably. Oh, wait, did I say "you"? I meant "me".

The ever-gracious Eve Andersson published my question. To see it, follow the link and scroll down until you see "mysterious envelope".

In other news: Snakes on a Plane!

I walked from U.C. Berkeley towards the BART station. I was at the tail end of a comics and library run. I'd picked up a few good books, and many good comics.

So my pack was heavy and it was hot and I directed my steps to a boba tea place--I was ready to sit down and drink something cold. Sitting at a table was Ian Tullis of the team Kittens Kittens Kittens. He was writing something in a notebook. I asked him if he was getting ready for BANG 10.

He wasn't. That made sense--Kittens Kittens Kittens was running BANG 10 the next day. But I'd play-tested a few of their puzzles a few days earlier, and they seemed to have their act together.

But he said he was working on puzzles. So I guess if Kittens Kittens Kittens runs any more puzzle hunts, they'll be ready.

Tags: puzzle hunts | batrachoseps |