Back in 1999, I traveled in New England. I told intrepid traveler Tom Manshreck that I was going to visit New Bedford. He said ""Yeah, man--New Bedford used to be a good place to go to--to get shot!" but that it was better now. The book Down at the Docks is about those aspects of New Bedford which made it a good place to get shot.

This book is... it talks about the people of New Bedford. There are a few, uhm, protagonists, locals who the author talks to. The book has slices-of-life from these folks. It also has swaths of city history. These are not nice people. These people are scary. New Bedford used to be a good place to go to to get shot. Murder, you bet. Rape--famous for rape. (And, in one incident, a rally in support of some rapists.) Junkies stealing anything that's not nailed down. Non-junkies stealing plenty, too. Sinking boats for insurance fraud. Setting fire to factories for insurance fraud.

Along the way, some darned good writing about some darned interesting people. Terrible things happen, but you can't look away, the book carries you along. Very recommended, but it helps if you have a strong stomach.

This is a popular book about how to be well-liked. The good news is that there's some good advice in here. E.g., try to see things from the other person's point of view. The bad news is that some of this good advice is hard to follow. Sometimes you see things from the other person's point of view, and you realize that they must be some nutjob who will never come to their senses and we're all doomed. Then you realize you've gone to all this trouble to see things from their point of view and you still don't know how to influence this person.

The worse news is... This book has been out for a while. This book has been popular for a while. Many people already know its more straightforward advice. I suspect that so many people know about it that... the world has changed. This book's advice is now backfiring. I'm pretty sure it backfires when people try to use it on me. This book suggests addressing people by name—people tend to respond to their own name. The thing is... nowadays, I tend to respond to my name by flinching. I think Oh gee, someone is following this book's advice and is trying to turn on the charm. What are they up to?

You're also supposed to compliment people sincerely. Maybe that's how I picked up another tic—I flinch when people compliment me. Usually it means they're about to ask me for a favor. "Oh, gee, you're so much better at cleaning tile grout than I am... How would you feel about cleaning the shower?" According to this book's advice, you're also supposed to compliment people even when you don't especially want them to do something for you at the moment. But not many people do this, so I shy away when folks start dropping compliments. I don't think I'm the only one who does this.

You'd think that this book would just have me cringing. Actually, it was an interesting book. Ghe guy who wrote it had some good ideas about how to teach people. It does some interesting things with repetition. There's a summary at the end of each chapter. There was a blank page at the end of the book, and I was encouraged to note down how I'd applied the book's lessons. It was a library book, so I was tempted to make up some funny anecdotes for the amusement of the next person to check it out, but in the end I didn't think of any.

This book, The Pragmatic Programmer is difficult to find by searching, since there's also a series of books by that name. So maybe I'll give the full title here: The Pragmatic Programmer / from journeyman to master. That subtitle sounds pretty highfalutin', at odds with the "pragmatic" in the main part of the title. But it does fit with this book's approach: treating programming as craft, trying to give direction to some folks who want to hone their craft.

This book is a survey of "best practices". It doesn't go into much detail on any one of these practices. So... for example... If you picked up this book thinking "Command Line Interfaces are relics of a stupider age," then you're going to see a section of this book which exposes you to the idea that Command Line Interfaces are awesome--but it won't give you enough detail to reverse your preconceived notion.

I'm older than dirt and have been in some well-run engineering organizations. Thus, I have already been exposed to these practices. I feel kinda sorry for someone who has to learn about these things from a book. If you've been in an engineering group that has a nice testing framework you appreciate it—especially if you then go to another group that doesn't have one. But if you've never used a testing framework, and if you just have this book telling you that it's a darned convenient thing, and you're going to the trouble of setting it up... I dunno if a book would convince me to take the trouble.

The authors are technologically aware, and have a pretty good web site about the book, with a table of contents and a list of "tips". If you're interested in reading a survey of best practices and want to make sure that this book contains the best practices you want to learn about, that table of contents might be pretty interesting to you.

Good grief, it's another pop psychology book. I've been reading a lot of these recently, it seems. I swear, if I have to sit through another discussion of children who can/cannot delay their consumption of marshmallows, I'm going to... Ahem, anyhow. I made it through this book.

Influencer is applied psychology. People don't reason logically. If you want to influence a group's behavior, if reason ain't working, what do you do? You can keep spewing facts, but maybe you'll just continue to watch those facts flop around ineffectively. Maybe you need to choose different material. Maybe you need to change up something else. Some more sources of influence to bring to bear:

• Get society on your side. People can watch each other, can encourage or discourage each other. They can spread and reinforce your message.
• If your message fails because you're an untrusted "outsider", try to convince a respected "insider" to deliver your message for you.
• If people fail to follow the abstract philosophy you present to them, show them some concrete things they can do.
• Or show them a story that makes the abstract, perhaps taboo, issues concrete. People identify with story protagonists.
• Choose rewards carefully. Esteem and respect often work. Money is dangerous.
• Can you change the environment? If you can't resist eating ice cream, maybe you should get rid of your ice cream freezer.

It's all good advice.

OK, there was one example that came up a lot that I hadn't already become sick of: the Delancey Street Foundation. I didn't know that much about their methods. I didn't know that so much of the recovery was up to the residents themselves, the wide application of "each one teach one". I can imagine that a new resident, showing up there, would adapt to fit in, and in so doing, would learn to operate in the world a lot better. But now I want to know how the system was bootstrapped—how did the first generation get it together?

This book, Engineering the City showed up as an Amazon.com-recommended book, probably because I liked Brian Hayes' book Infrastructure so much. I kinda wish I'd paid more attention to the details of Engineering the City before I went to the hassle of requesting it through the LINK+ inter-library loan program. Not that it was a lot of hassle, but... Well... This book is for ages nine and up. I bet it's a very nice book for what it is. But. I went a ways through it, and it wasn't telling me much I didn't already know.

There was some new-to-me material--a few sentences about the history of construction of a harbor at Ostia. (The Romans built a couple of breakwaters, which were nice but not enough, so they built another one.)

The builders of the transcontinental railroad got a bonus built on mileage--before the "golden spike" was driven, there was a period of time when they were building parallel tracks, because the senate hadn't yet said "hey, we're only paying for one railroad, you west-bound builders and you east-bound builders have got to meet somewhere". That's neat stuff.

But I don't want to wade through a quick explanation of where rain comes from. And another quick explanation of something else I already have heard. And another and another.

Probably a darned good book for someone ages 9+. But not for me, I stopped partway through.

It's going to sound like I'm slamming this book, like it's bad. It's not bad. I just chose the wrong book, is all. The thing is: this is an academic work. [It might also sound like I'm obscurely referring to recent events. But, as usual, I had this book report sitting around in my queue for a while.]

This is an academic work about the effect of the internet upon civil society in China. By "academic work", I mean that... Well, for example this book's first chapter is a careful definition of "civil society". I guess. I mean, the book's intro warned me that's what the first chapter was going to be about, and that it would refer to Hegel. Hegel. Good grief. So I skipped the first chapter, since that was just going to be of interest to a few scholars.

Alas, the rest of the book is academic, too. It was tough to find useful bits amongst the hair-splitting arguments with others' work. Eventually, I stopped reading and started skimming.

There were nevertheless some worthwhile bits. This book taught me some things about China's administration of censorship. I assumed that the national censors had direct control over local news--but apparently, national censors control national news. Local news is under the control of local governments, which have their own censorship rules. So I thought that regional differences in censorship were mostly local corruption, but it turns out that some of those regional differences are legal.

This leads to an interesting pattern--local politicians worry about national news organizations. Just as a sherriff might help prop up a corrupt local government, in China a local news organization helps cover up illegal activities of local government. But just as the USA's feds might trump the sherriff, Chinese national reporters might expose local corruption since the local officials don't have power to stop them.

That was kind of neat. If it's true. I might have misinterpreted. Try wringing meaning out of a sentence like "Notwithstanding the Habermasian normative perspective of public opinion formation and its crtics, there has been a well-established line of research about the impact of public opinion on political governance (e.g., Heith, 2004; Manxa, Cook, and Page, 2002; Sharp 1999) and the theory and practice of accurately gauging public opinion (see Ferguson, 2000 for an overview) as well as the role of mass media in shaping public opinion (e.g., Perse, 2001)." Eventually figure out it's not saying anything about the book's topic, but is just anticipating debate about whether anyone can say anything about the topic... Oy veh.

There are probably a couple of dozen scholars who want to read this book. I eventually realized I wasn't one of them and stopped.

It's a collection of short stories. Easy-to-read stories about folks going through tough times in their lives. The protagonists tend to be thoughtful persons of color surrounded by not-so-thoughtful people. What do you want to bet that this tells you something about the author?

Good writing can help your work's longevity. But it doesn't fix everything. Mountaineering in the Sierra Nevada is a well-written book. It's from 1872. Charles King was a good writer. But... it was 1872.

Back then, there weren't way too many color photos of Yosemite cheaply availableto the public. So if you were writing about the Sierra Nevada mountains, you felt obliged to describe them, you know, verbally. Sure, a picture is worth a thousand words, but back then, pictures were expensive... so it was cost-effective for a writer to write a thousand words. So the present-day reader finds himself slogging through piles of verbal description, muttering "Yeah, you like the mountains, it's okay we understand."

Also, back then racism was pretty normal. It's tough to read what King wrote about some people of his day. He wasn't mean-spirited. But he was wrong. He didn't like Chinese cooking. I thought back to Chinese immigration in Texas, German immigration to Texas, and how El Paso food turned out so bad compared to that of San Francisco. But it was a near thing. What if more Californians had listened to Charles King?

But if you can get past that, there are some good parts.

There was no foothold above us. Looking down over the course we had come, it seemed, and I really believe it was, an impossible descent; for one can climb upward with safety where he cannot go downward. To turn back was to give up in defeat; and we sat at least half an hour, suggesting all possible routes to the summit, accepting none, and feeling disheartened.

Now I don't feel so bad about falling down while stumbling down some trails I'd had no trouble climbing up.

On history of architecture versus geology:

In the much discussed origin of this order of building [Gothic], I never remember to have seen, though it can hardly have escaped mention, any suggestion of the possibility of the Gothic having been inspired by granite forms. Yet, as I sat on Mount Tyndall, the whole mountains shaped themselves like the ruins of cathedrals,--sharp roof-ridges, pinnacled and statued; buttresses more spired and ornamented than Milan's; receding doorways with pointed arches carved into blank façacdes of granite, doors never to be opened, innumerable jutting points with here and there a single cruciform peak, its frozen roof and granite spires so strikingly Gothic I cannot doubt that the Alps furnished the models for early cathedrals of that order.

He visited the top of Yosemite falls in October, as did I, and his experience was similar:

In this strange, vacant, stone corridor, this pathway for the great Yosemite torrent, this sounding-gallery of thunderous tumult, it was a strange sensation to stand, looking in vain for a drop of water, listening vainly, too, for the faintest whisper of sound, and I found myself constantly expecting some sign of the returning flood.

I bought this book because I was in Yosemite and found out that my mobile phone's data connection wouldn't work there. This book spared me some hours of boredom. It has its good parts. And if some parts haven't aged so well... It's a good thing for a reader of any time to remember to keep his wits about him as he reads.

Cousin Eric was in town this weekend. There was some sight-seeing. One place of interest was Berkeley. My parents pointed out some places of interest for the Free Speech Movement: here was the place where folks stood atop the police car. Ah, Berkeley history, the subject of The Berkeley Pit.

It's a history of Berkeley's Telegraph Avenue; it's a story of a place turned toxic; it's a story of liberals ripping each other apart. It's "an historical novel", a story of Berkeley that reaches from the 60s to the 80s.

One of the story's protagonists is from Butte, home of The Berkeley Pit, a huge abandoned pit mine, a superfund site, a hole in the ground full of toxins. In perhaps a dozen years, enough water will leach into the pit to overflow, sending out an evil flood to poison Montana's water supply. Where did the Berkeley Pit come from? Our protagonist found out by studying his family history. Butte was a copper mining city. It wasn't always a pit mine. But when the copper started to run out, the mining companies dug the pit--tearing down the city itself to dig.

The protagonist comes to Berkeley and sees the same thing happen again. Folks in Berkeley and Oakland, trying to make the world a better place. It's the time of the Free Speech Movement. There is a resource to be mined here--a community of people willing to act. But as time goes on, saner voices are shouted down by those who don't care what the protest movement does but know that if they protest something then they can lead that protest.

The narrator--not to be confused with "the protagonist" (OK, really, the book has more that one protagonist, depending on how you count these things)--is strange. She is a writing teacher; she encourages her students to write clearly, strongly, not hold anything back. And yet we know she does this herself. When corresponding with our protagonist...

I saw no need to send Harry bad news from here, bbut perhaps I should have mentioned, for instance, the first murder in People's Park. Instead I wrote him about our "Writers' Campus Sit-in" for divestment in apartheid South Africa... I sent him a photo of my grand-daughter, but I never sent the Daily Cal photo of two middle-aged "progressive" city council members grinning in fierce defiance at constituents (including me and my neighbors) who had defeated another of their misbegotten schemes.

It's painful to write about the sometimes-bad results of our well-intended acts. You try a lot of stuff; it doesn't always work out. It's not nice to face the fact that your stuff didn't all work out well, to tell other folks about it. But if we don't do so, others follow in our footsteps.

Years pass; hippies retreat to their houses. A few street people are still good-hearted free spirits, but they are mostly crowded out by thieving addicts and kids playing at homelessness. That guy who used to live in a communal hippie squat is now running a crack house.

Along the way: the Black Panthers, Peoples Park, the rise of AIDS. Oh, and the hard life of Berkeley bookstores: this book goes well with The Loneliness of the Electric Menorah, the Codys keep showing up.

A bleak book and a darned good read. Check it out.

This is the book that the movie "There Will Be Blood" was based on. But that's not how I heard of this book. I saw Word for Word perform the first chapter. This group acts out short stories and stuff--but instead of just giving the dialog, they give all the words from the book. It sounds like a stupid idea, but it turns out to be pretty darned good. Probably because they choose material that works well. And are good actors.

Anyhow, I was in Chicago and needed a book to keep me from going insane on the flight back home. At the IIT bookstore, they had a lot of books about architecture and engineering and not much else. This was one of the books in the "else" category. I didn't have high hopes. But this book was pretty good!

It's a story of oil and moviemaking in Southern California. It shows you how the Southern California economy works--that is, largely through bribery. (It doesn't really talk about water rights... but it talks about enough.) It's sorta like Candide set in SoCal--the son of an oil magnate grows up with good intentions, and gradually figures out why society's machinations cause so many people to have rough lives. The sad part about this book is that it holds up Communist Russia as the system that would save the people from their misery. But... this book was written back before WWII, and word hadn't gotten back that the Commies were just as corrupt as the capitalists.

Ah, corruption. There's the old saying that an honest politician is one who stays bought. This book had a variation.

Now [the politician] was to give the oil men a whole string of valuable leases for practically nothing; but he had to have more money. That was the trouble in dealing with politicians; you bought them before election, and then you had to buy them again after the election, they wouldn't "stay put," like business men.

When I go back and re-read that paragraph, it sounds like the book is a total downer. But it's funny. I meant what I said about Candide--this book is has bleak humor. It's good. Check it out.

It's Derek Powazek's 2002 book about making web sites that work well for communities. There were examples of things that worked well, things that didn't. A lot of this material is stuff you get to hear about already. There was one insight, one new way of seeing things that I liked: if you want higher-quality comments from users, your comment form should be less "usable". Your instinct as a web designer is to keep things easy, free, and open. But that ease-of-use also means that a bored 12 year old boy has an easy time posting "yermom" on your site. So if you're getting too much low-quality user input... move the post button to someplace less obvious. Maybe require a sign-in step.

This naturally made me think about Youtube comments, famous for inanity and mean-spirited-ness. Each user "pinned" to a page because he's watching the embedded video. If the video's a couple of minutes long, he's got a ocuple of minutes of half-attention with nothing better to do than write an awful comment. Maybe he should have to jump through more hoops first.

It's a biography of Warren Buffet. It's pretty long. But there are some good stories in here, the writing is good, and it smells well-researched. It edges around some touchy topics, but it's pretty easy to tell when that's going on; there are plenty of touchy topics it doesn't edge around, but dives right into.

["Jet" Jack Ringwalt's] first break had come when a bank asked him to guarantee that a bootlegger—presumed murdered—would not return to Omaha, because the presumptive widow wanted to withdraw his account without waiting the legally required seven years. Ringwalt figured the alleged murderer's lawyer might have a pretty good idea whether the missing bootlgger's blood no longer pulsed. He had helped the accused murderer beat the rap, but the dead man's widow (and the bank) suspected that was mainly just good lawyering, not exoneration. Still, the lawyer couldn't say whether his client had confessed to him. So Ringwalt got him to put up some of his own money on the guarantee, on the thory that unless the bootlegger had croaked louder than a bullfrog, the lawyer wouldn't take the risk. Sure enough, the cash told all; the bootlegger never reappeared, and the bank never made a claim...

Puzzlehunt fans even get a relevant phrase: Another Ringwalt story illustrates "Only Game Control thinks that's funny" conflict-of-interest:

...then he put up the stakes for radio-station treasure hunts, hiding the clues in lipstick cases, burying them himself, using clues so obscure that only one prize was ever claimed.

A story about Warren Buffet as he cleaned up after an illegal trading scandal at Salomon Bros: he cut loose a P.R. firm that had been newly hired to shape news about the scandal.

"It wasn't that we're misunderstood, for Christ's sake," said Buffet afterward. "We don't have a public relations problem. We have a problem with what we did."

A note about the power of computer games--as of 1991, Buffet still wasn't using a computer to do his research, his writing, etc. He hung out with Bill Gates who tried to convince him to use a computer, but nothing doing. But he finally started using a computer when his bridge partner told him he could practice (and play) bridge by computer. People talk about Visicalc, but once again, computer games are really what got folks to sit down at the monitor... yeah, anyhow. A fun read.

It's a book about the Soviet invasion of Afghanistan, telling it from the Soviet point of view, based on interviews with Soviet soldiers. It's like a horror movie where you want to yell at the characters, "No! Don't go in there! Haven't you studied the genre?" But this is one of those stories that defined its genre.

The Soviet Army went in without a goal. It's not clear that they ever really declared war against Afghanistan. Just started moving troops in, took some territory over. They thought they'd be welcomed as folks replacing corrupt leaders with good government, but it didn't work out that way.

Suppliers were supposed to supply the Soviet troops. But suppliers were corrupt and those supplies went elsewhere. Starving, the Soviet troops stole from the locals. Theft did not convince the locals that this was a liberating army... more like a looting horde.

The war dragged on. At first, the Soviet tactics failed them when they went up out of the valleys, into the mountains. They had tanks, good for flat land. Eventually, as the war dragged on, the Soviets got better at dealing with the mountains. But it still wasn't clear why they were there, what they were trying to accomplish, when it would be time for them to go home. The local army wasn't eager to fight the mountain rebels.

Other countries gleefully sent weapons into the area. The USA Stinger anti-aircraft weapons took out many helicopters.

There was death, there was betrayal. There were good things, too.

Eventually, the Soviets pulled out. The war veterans were treated like heroes... for a little while, until the USSR fell apart. Plenty of them were pretty messed up physically, mentally.

It's a sad story.

I got kind of tired of space marines. Maybe I played too much Quake, back in the day. Broken Angels is a book about space marines. Sort of. Close enough. I didn't really get into it, but I'm not sure that's the book's fault. It just might have been... too many space marines.

Last week, I posted a rough draft of a study guide for The Mythical Man-Month. I left a cheap joke out of that study guide. That study guide was serious business and had no room for cheap jokes. So I'm posting this separately.

One part of the book discusses how to divide up a programming team's labor among a few people, letting the best programmer concentrate on programming, while offloading minutiae to others. They use the analogy of a surgical team:

A proposal by Harlan Mills offers a fresh and creative solution. Mills proposes that each segment of a large job be tackled by a team...organized like a surgical team... one does the cutting and the others give him every support that will enhance his effectiveness and productivity. ... Can it work? Who are the the anesthesiologists and nurses on a programming team, and how is the work divided?

Because I'm a technical writer, I was flattered that this proposed team has a role for a technical writer: the Editor.

The editor. The surgeon is responsible for generating the documentation—for maximum clarify he must write it... The editor, however, takes the draft or dictated manuscript produced by the surgeon and criticizes it, reworks it, provides it with references and bibliography, nurses it through several revisions, and oversees the mechanics of production.

Why mention a tech writer? Maybe Brooks was thinking about this because he was writing a book. I have another theory, though: he wanted to answer the question he raised earlier: Who is the anesthesiologist of the surgical team? Anyone who's tried to stay awake while reading my documentation can answer that question. Uhm, they can answer it after you wake them up again, I mean.

If this book report seems a little heavy on the questions? It's because it's the first draft of a study guide? For people reading the book? Oh man it's way too long? But hey give me a break, it's a first draft?

The Mythical Man-Month

This is a study guide for folks reading the Mythical Man-Month. When reading a book like this, it's useful to have some questions buzzing around in the back of your brain. In case you don't already have enough of those, this study guide provides a few extra.

This book is about managing large software projects. Fred Brooks wrote it in 1975; back then, there wasn't a big literature about such things. There hadn't been many such projects. Many of them had been debacles; nobody wanted to brag about them later. Actually, Fred Brooks had presided over something of a debacle himself--his project was famously late. This book is a post-mortem: why things went wrong, lessons learned, how we can (or why we can't) avoid similar stumbles.

Pick up a recent edition of the book--the 20th anniversary edition includes chapters at the end pointing out which parts of the original have [not] withstood the decades. E.g., the Waterfall Method of project planning isn't SOP anymore. In the preface, he also points out something important about software project management reports in general:

In preparing my retrospective and update of The Mythical Man-Month, I was struck by how few of the propositions asserted in it have been critiqued, proven, or disproven by ongoing software engineering research and experience.

As you read this book (or anything), always be on your guard for snake oil, untested assertions, and handwavery. Some techniques will help your team, some will harm it. Learning to recognize which are which is an important part of leadership.

Preface to the Original edition

Brooks gives us the whole book in a nutshell in the Preface.

I wanted to explain the quite different management experiences encountered in System/360 hardware development and OS/360 software development.

...

Briefly, I believe that large programming projects suffer management problems different from small ones, due to division of labor. I believe the critical need to be the preservation of the conceptual integrity of the product itself.

Got that? He's telling us that Management is important. He's saying that Leadership is important. He's saying that Design is important. 120 people produce no more than 12 do if they're not working towards the same goal. And unless you can help them all see where that goal is, they will not all work towards it. He's not going to teach you new algorithms, tools, none of that. This is people skills. He's reminding you that this stuff matters.

The Tar Pit

Brooks' OS/360 debacle was largely a schedule slip. Here, he points out that junior programmers are optimistic about how long it takes to implement part of a large system. They don't think about the (considerable) time it takes to provide the correctness and polish they'll need to be part of a real-world product. the (considerable) time to design and implement the interface between their system component and the rest of the system;

Try to remember your first projects working on larger software systems. It took longer to get things done than your quick-and-dirty hacks for school homework assignments, didn't they? Where did the time go?

As a rule of thumb, I estimate that a programming product costs at least three times as much as a debugged program with the same function... A programming system component costs at least three times as much as a stand-alone program of the same function.

If you're not sure whether a junior programmer has considered these things, their schedule guesstimate might be 9x optimistic. When you get an estimate from a co-worker, how can you find out whether they've allowed for correctness and API design?

In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment.

The Mythical Man-Month

Here, Brooks points out more things that go wrong with managing schedules. They're hard to estimate. They're hard to boost, too. This chapter gives us Brooks' Law: "Adding manpower to a late software project makes it later." When you add new people to a project, for the first few months, they slow you down as you teach them things and they bump into things. Only later when they're up to speed might they help your schedule. Unless they slow down trying to manage them.

Why would anyone ever think to throw people onto a project at the last minute? Maybe a clue is the context in which this book was written, IBM in 1975:

I wanted to explain the quite different management experiences encountered in System/360 hardware development and OS/360 software development.

Maybe back in 1975, most of IBM's experience was with hardware. If design went slowly, maybe there was a temptation to make up time with more people: run extra shifts at the manufacturing plant.

The need for intercommunication slows everyone down. Can we ease this by designing better interfaces? Can we design our software architectures so that not every engineer needs to pester every other engineer to learn every interface?

Gutless estimating It's bad enough that the junior engineers on your team underestimate how long it will take them to accomplish something. Sometimes an executive does, too. They lean on you, that's no fun. Something that happens at often at some companies: someone pre-announces an unrealistic date to the world. Do you have any stories like this? If not, ask some veteran programmer to tell you some. Maybe buy that veteran a drink first--they tend to be sad stories. In hindsight, could the teams have dodged these disasters?

The Surgical Team

This chapter explores the idea of a small programming team. Some parts of this idea have aged better than others.

Aged well: team of people with complementary roles and diverse skill sets.
Aged less well: some of the suggested roles now seem absurd.

Brooks thinks that every senior programmer needs a secretary. And an editor (tech writer) and another secretary for the tech writer. Brooks was a writer in a time of typewriters, large presses, and other awkward tools. Nowadays instead of giving the senior programmer so many people to manage correspondence and documentation, we have Gmail and the wiki. The "program clerk" role largely went away when revision control systems came along—a few admins can "clerk" the "programs" of many, many engineers.

Suppose you wanted to plan a "surgical team" for your organization in the modern day. What roles would it have? What assumptions do you need to make about how this team would fit in to the organization at large?

Aristocracy, Democracy, and System Design

If one person designs a system, that design captures only one person's knowledge. For a large system with many differrent pieces, some pieces' designs will be clunky.

If many, many people design a system, that system never gets designed.

Brooks praises Reims Cathedral:

The joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. As the guidebook tells, this integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design.

Invoking a cathedral as metaphor might set of alarm bells in your head. Didn't ESR use that same metaphor in his essay The Cathedral and the Bazaar? There ESR praised the "bazaar" over the "cathedral": harnessing hundreds of open source folks to work on a project instead of a small, limited group. But that essay points out that some tasks scale better than others. He wrote

So does the leader/coordinator for a bazaar-style effort really have to have exceptional design talent, or can he get by through leveraging the design talent of others?

I think it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others.

Brooks and ESR would agree that you can't just let loose a horde of 150 programmers and hope that a great design emerges. You need some architects with "taste".

How much of a system's design should the architects figure out (leaving details to the horde)? Brooks thinks it's the interfaces: the APIs and UIs:

By the architecture of the system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a compiler it is the language manual. For a control program it is the manuals for the language or languages used to invoke its functions. For the entire system it is the union of the manuals the user must consult to do his entire job.

Suppose you're Fred Brooks and you have 15 great programmers and 150 good ones. How might you divide tasks between them? What are some ways you could set up bottom-up feedback without drowning in noise?

The Second-System Effect

Have you ever worked on a "second system"? You work on a successful system. It's working. You look for ways to improve it, to "get it right." You get around to elegantly adding those improvements that you couldn't "bolt on before". And somehow... the result is a mess. Years later, you figure out that many of those "improvements" were gratuitous; some of them made the system worse. Have you? Or seen one from a distance?

How can we guard against this effect? Brooks says every design team needs a third-system veteran, someone who has experienced their second system. How might a system like this work at your organization? Anyone can design something, you can't force them to take advice from a veteran. What can you do?

Passing the Word

This chapter is mostly of interest to the historian, or people who like to hear stories of the old days when "we had to walk back and forth through the snow, twenty miles, uphill both ways".

The book assumes that most of a project's "architecture" happens up front, then stays frozen. Wow, it's the opposite of agile. This chapter explains the clumsiness: This chapter talks about project communications back in the 1970s.

Back then, communicating a spec change was a major ordeal. Word processor software was a newfangled clunky thing. There was no revision control system software to keep track of changes. There was physical typesetting; physical pages to truck to far-flung teams.

The section titled Conferences and Courts talks about their change process. He mentions that it happened less often than it should have--Brooks wishes that his architecture team had been more agile. But when you hear about what it took to communicate a change... it makes one glad to be working in these relatively easy times.

Why Did the Tower of Babel Fail?

It's another chapter about the difficulty of communication, but this chapter describes problems that are still with us.

So it is today. Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn't know what the right hand is doing.

Part of the chapter describes the 1970s solution: write everything down. Since they didn't have an intranet and a wiki, and they generated a lot of information, they used microfiche. Ha ha ha. If you get bored reading about 1970s communications technology, you might skip ahead to the section titled Organization of the Large Programming Project

Like the "Surgical Teams" chapter, this section discusses roles. But instead of people working on a small team, these roles are the "diplomats" that keep those teams moving in the same general direction: producers and technical directors. If you work on a large project, who are the people who have this high-level role? How would you decribe their roles? What challenges do you think they face?

Calling the Shot

This chapter has more ponderings on schedule estimation, including some still-relevant thoughts about why things might take longer than you'd expect. Along with this, there are some good reasons for "fudge factors" to apply when you hear a schedule from a naive estimator.

Have you ever estimated how long it would take you to complete a task? How far off were you? Why?

Has someone else ever estimated how long it would take you to complete a task? Why was their estimate so far off?

Have you ever estimated how long it would take someone else to complete a task? How far off were you? Why?

This chapter measures programming output in Lines Of Code. Yes, people really did this back in the 1970s and '80s without irony.

Ten Pounds in a Five-Pound Sack

This chapter discusses the tragedy of metrics: once programmers know what you're trying to measure, they will optimize for it, sometimes at the expense of overall system quality. E.g., if you tell programmers to use less memory, you might notice the system slows down with swapping:

...Digging-in showed that the control program modules were each making many, many disk accesses. Even high-frequency supervisor modules were making many trips to the well, and the result was quite analogous to page thrashing.

You need to measure things, but leaders need to make sure that things stay on track.

The project was large enough and management communication poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products.

Have you seen this kind of problem, where a high-level strategy gets mis-applied at the low level? Could a different approach have yielded the benefits without the low-level problems?

Representation is the Essence of Programming is a fun section, reminding us of the importance of designing our data structures.

The Documentary Hypothesis

Brooks was a writer; it's no wonder that he advises that a project's mission, architecture, and everything be expressed in writing. This chapter describes some things worth writing down. If your customers can see your source code, then API documentation is simple. But he wants more.

One document he suggests maintaining is an org chart:

This becomes intertwined with the interface specification, as Conway's Law predicts: "Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations." Conway goes on to point out that the organization chart will initially reflect the first system design, which is almost certainly not the right one.

Even with our great software tools, editing an org chart is tricky. People get tetchy when you mess with it. Some inertia is good. Brooks advises some inertia in changing system documents, too... and not just because of clunky 1970s documentation technology:

...the best engineering manager I ever saw served often as a giant flywheel, his inertia damping the fluctuations that came from market and management people.

Have you worked with customers before? What sorts of second-guessing have you had to apply to their suggestions? How do you prioritize their requests?

The task of the manager is to develop a plan and then to realize it. But only the written plan is precise and communicable.

How much precision do you want in a plan? Are there other ways you might communicate it?

Plan to Throw One Away

Twenty years later, Brooks was no longer fond of this chapter. This chapter points out that your first attempt at implementation might not be good; it's OK to scrap it and start over. Later on, as he moved away from the waterfall model, Brooks was OK with the idea of more incremental improvements.

But there's still some good advice here:

Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.

Have you ever been on such a project? Did your customers forgive you?

Plan the Organization for Change reminds us of tricky things to keep in mind when changing things.

Management structures also need to be changed as the system changes. This means that the boss must give a great deal of attention to keeping his managers and his technical people as interchangeable as their talents allow.

I'm not sure I've ever seen a management structure change that was described as in response to a system change. Have you? What was the reason? How was it communicated?

Sharp Tools

This chapter is mostly of interest to the historian. It's a fun read, but if you're in a hurry, I'll summarize it for you: tools are better now than they were in the 1970s. We gripe about our tools, but they are awesome.

The Whole and the Parts

This chapter discusses the creation of high-quality systems:

• Writing a spec clear enough such that folks know what the system is supposed to do.
• Test the program.
• Debugging: excel at it.
• Don't try to integrate all changes at once.

Have you worked on a large project? How did the project find bugs hidden in the spaces "between" modules worked on by multiple teams? Did teams do anything to make this easier?

Hatching a Catastrophe

Earlier, we learned that everyone is terrible at estimating software development schedules. Here, we learn that they're also terrible at noticing schedule slips. He recommends using scheduling software to find bottlenecks and watch those carefully.

The bosses also need to let underlings safely report schedule slippage.

Have you worked on a project that had a schedule?
Have you worked on a project that did not have a schedule?
Any differences in the projects that could be attributed to the difference?

The Other Face

This chapter discusses how your product interacts with customers: usability and documentation. Some parts of this chapter have aged better than others.

The flow chart is a most thorougly oversold piece of program documentation. Many programs don't need flow charts at all; few programs need more than a one-page flow chart.

Flow charts have fallen out of favor. What would you say are the most oversold pieces of program documentation nowadays?

The chapter has some interesting ideas about using code comments to clarify code. What did you think about using ASCII art arrows to show the path of GOTO statements? Do you still think C is a primitive programming language, now that you've seen PL/I?

No Silver Bullet--Essence and Accident in Software Engineering

If you're reading an old edition of the book, you don't have this chapter. Fortunately, it's out there in a place called the internets.

This 1987 essay points out that software development had made great strides recently. Software development was getting faster! But the easy speed-ups were gone: the remaining problems could not be so easily knocked down with tools.

Our tools were getting really good at dealing with the same problems. But the essential problems hadn't been tackled at all.

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.

Putting together a software system isn't like assembling homogeneous bricks.

...it is necessarily an increase in the number of different elements. In most cases, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly.

And of course, by the time you design a decent solution, the requirements have changed

The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture; they are superseded by later models, or essential changes are incorporated in later serial-number copies of the same basic design.

How can we approach some of these essential problems? If we want to do something similar to what others have done before, we might be able take advantage of their work; e.g., if you want to write a simple database-backed web application, there are several platforms that make this pretty easy. But probably the very fact that you're thinking about large-scale software development means that you're thinking about some project that's not so straightforward.

When you consider the lifetime of a major software project: the evolution from hallway conversation to design to tinkering to large-scale development to refinement to deployment to support to maintenance and improvement: where does the time go? If you wanted to accomplish all this with half the effort, what would need to change?

Some of Brooks' possible-solutions-on-the-horizon have come to pass, at least partially. Are there any of these that you think might speed up software development further in the future? Or have these veins been mined out?

I used to read a little newsletter called 2600. It billed itself as The Hacker Quarterly, which makes it sound like it was full of sploits for breaking in to computer systems. But it wasn't really about that. It described a bunch of computer and telephone systems. For each system, the point of view was someone exploring it, who'd figured out a few things. I eventually figured out that the article authors mostly weren't breaking into the computers. Rather, they'd got some student account or one of their parents had let them mess around. And I wasn't even into cracking into computer systems (and still ain't). And yet... And yet... yet, it was still an interesting newsletter. This was before the web, and there wasn't much good high-tech journalism out there. Most of that was aimed at specialties, at businesses. 2600 talked about many different kinds of devices.

Nowadays, I get my tech news off of the internets. Still, when I heard that there was a "best of" anthology coming out, I figured that it would be good for nostalgia. And it was.

TelCo minutiae in How to Get Into a CO, "The Kid" describes how he and some phone phreaker friends arranged to get a tour of their local telephone company facility. The most important thing that they learned "the mystery of the billing tape! Exactly what does it contain? The tape contains records of the following types of calls: 0+, 1+, and 7-digit numbers out of your local calling area." Uhm, yeah. If you want to work around phone company systems or social-engineer phone company employees, you need to learn how the phone company works. These kids got excited about billing system administration.

Voice Mail Systems Phone phreaks had phones. They didn't all have PCs or email accounts. So instead of sending emails or going onto computer BBSs, they liked voice mail systems and phone conference systems. Some company would get a voice mail system. Every employee got a mailbox with a default password, maybe "1234". Most employees never used the system, never changed their password. So... the phreaks used these systems as message drops. Looking back now, in these days of free email accounts all over the place, it's hard to imagine that folks would need to "hack into" a system just for a place to exchange messages.

Not by "Crackers" A "how to" article on privelege escalation on VMS systems--which mostly consists of debunking some obviously-bad advice which, apparently, was going around at the time...the article ends with "...If you have not guessed by now, I am a VMS system manager. I am assuming that many of the people who are reading this are other system managers who, like myself are trying to keep hackers off of their systems."

Civil Liberties In 1997, spreading the news that cellular phone operators in India were providing help with phone taps to the government. Raids by the FBI and the Secret Service. (You want to know why American security folks keep mentioning "subpoena" in their threat models? Geeks of a certain age grew up hearing about the Secret Service raiding... raiding a game company, seizing their computers... Not even a computer game company, but a reputable paper-and-pencil game company... And plenty of other raids, similarly dubious. High-profile arrests which probably got some federal agent promoted. Charges eventually overturned. Or the incredibly valuable stolen data turns out to be available from the local college library and we find out we paid millions of dollars in taxes for a raid and a trial over a crime whose stakes were less than grabbing the till from a lemonade stand. Or... or... Ahem. Sorry, was I ranting?) Various attempts by the USA government to popularize key escrow encryption--in which the government is the escrow.

The Pay Phones go Away Remember pay phones? They used to be all over. Now they're in... they're in... they're in BART stations, I guess. Not many other places. Mourned in conversation, but largely overlooked by the news. But 2600, bless their phreaker hearts, noted their passing.

2600 is still a going concern, but I stopped reading it as various web tech news sites got better. Still, for me, this collection brought back memories of the late 90s, the early aughts. Though the systems have all changed, we're still applying lessons from those days. (Like, "1234" is not the greatest default password.) Geeks of a certain age might like this collection. I did.

I used to work for a lady named Lee Ann Fujii. She was pretty cool, so when I heard that she wrote a book, I figured I'd read it to see what she's been up to. She's now a foreign policy wonk specializing in Rwanda... so this was an intense read.

Before I ever heard from LAFujii about this stuff, I knew what "everybody knows": the Rwandan genocide was the result of ancient tribal conflicts between the Hutu and Tutsi once again boiling over. Except, it turns out, that's not quite right.

Back when Belgium had a big colonial empire, they spread that story of the Hutu, the Tutsi, and the Twa. But those weren't ancient tribes. They were recent creations--but it was convenient for the Belgians to say that they just wanted to deal with the Tutsi. So they kept re-telling the Hutu/Tutsi/Twa thing until it seemed natural.

But that's stuff that I'd heard years ago. There's more in this book. In this intense book.

This book has interviews with folks who were there during the killings. This book has interviews with witnesses. This book has interviews with killers.

The book has a thesis. These killings--they weren't really a genocide. This was mass murder, but not necessarily directed at a tribe. If a local gang leader wanted someone killed, they could probably have that person killed, no matter what tribe that person was in. It was easier if that person was Tutsi, but... But people switched tribes. If you were a Tutsi, you could follow the survival strategy of saying your were Hutu and, you know, go find some Tutsis to kill. Or you could just bribe gang leaders to overlook you. The official story was racial conflict--but when you looked deeper, it seemed more like killers used racial conflict as an excuse to kill enemies, to boost prestige, to pillage. There was even a, uhm, community-building aspect--one way to build community is to share experience--like, say, killing your neighbors.

So... that was bleak and cynical.

But it gets more intense than that.

Because

Because when you look at the details, it seems like something that could happen here. It seems like something that could happen anywhere. If you say "ancient ethnic hatred", that sounds unlike where I live. But when you break it down into cases, and you see how killers can talk themselves into killing.

On 9/11 2001, Islamic fundie terrorists killed many Americans. Some Americans responded by attacking Sikhs. That was tragic, ignorant, and awful. It stopped. What if it had kept going. What if local leaders had seen a way to consolidate their power by demonizing "towelheads"? What if our government had spread rumors that secret cells of turbaned terrorists were plotting to aid an immanent invasion?

That didn't happen. But when you see how it went down in Rwanda, you think "Yeah, I can see how people would react that way. Yeah, and I can see how that could lead to that." All the way up to killings.

Read it on a day when you'll be out with friends later so that they can cheer you back up again.

It is a new book by China Miéville. It has a creepy premise, and is very paranoid. There are two cities which occupy the same geographic space. How do they coexist? Citizens of each city have to pretend not to notice the other city. Anyone caught noticing the other city gets disappeared by a mysterious force called "Breach." I rather liked this book. I thought I'd figured out its final twist about halfway through. But I guessed wrong; there was less end-twisting than I expected. Which is fine! It's not like you're going to come to the end of this book and say "I expected one more gratuitous complication. It is supposed to be a thriller, right?" No, no, really, there was plenty of complexity here; complexity, paranoia, and magic.

Memoirs by some guy who was employee #55 at Amazon.com. He was an in-house editor. Amazon wanted to have some folks on staff who could write up book reviews. This was before they let any bozo with an account write a book review. Folks were supposed to trust these reviews--sort of like when you go to a physical bookstore and there's a piece of paper stuck to a shelf saying "STAFF PICK!". It seems like a silly idea, but these were the beginning days of Amazon, and nobody really knew how a retail site was supposed to work. Merchants and customers were still figuring that stuff out. Are still figuring that stuff out.

This guy used to pick some book that appears on the Amazon front page. I found myself thinking, how presumptious to think that he should do such a thing. But recommendation engines weren't so great back then. Having some human pick one book a day to show to everybody--that was probably the best option they had at the time... Nowadays, I ignore the Amazon front page and click through to the recommendations. It's not exactly clear to me why there's still a "front page".

What? Oh, right, the book.

The book. He talks about the scandal when customers found out about the payola. Book publishers wanted their books to appear on the front page and on category pages. Depending on which books the Amazon editors picked, the book publishers would fork over payola. You might think that the big publishers are sleazy when they lie to authors about copyright--but they're sleazy in plenty of other contexts, too. Anyhow.

So there was this big editorial staff at Amazon. But they weren't as good as crowdsourcing. There are too many folks on the internets who will write book reviews for free. (Maybe I should point out that I found Harriet Vane's customer review of this book particularly on-target.)

So there was this big editorial staff at Amazon. And then there wasn't.

So this is the story of someone working at a fast-growing start-up--who finds out that he's part of an experiment that's not working out... This would be a pathetic story, but the author, James Marcus, is an engaging writer.

And it's a reminder about the entrepeneurial throw-stuff-at-the-wall-and-see-what-sticks approach. I like this approach, it's a great thing to do with software. If you write some software that doesn't catch on, that's not a problem. But this approach, it doesn't work so well with people. If you say, "Hey, I know, let's hire a bunch of in-house editors" and that experiment doesn't work out, you're going to have to lay a bunch of people off. And that's hard. So I guess I'm saying don't throw people at the wall to see if they stick. Or something.

(Beware: Chapter 14 of this book is all about literary crap: What would Emerson have thought of the internet? You might not think you care about that idea now. You will care much less about it after you drag your eyeballs over Chapter 14. Things get going again after that, though.)

It's a book by Lawrence Lessig from 2008, and therefore it's about copyright law. (Nowadays he does election finance reform. Back then he was all about the copyrights.) It's about mashups. It's aimed at lawmakers, letting them know--each time you give more power to copyright holders, you aren't just making Mickey stronger. You're also outlawing art; much of art is reinventing prior art. "The bad artists imitate, the great artists steal," as Banksy recently appropriated.

I guess that's what this book is about.

I didn't make it very far. Hey, give me a break, I hang out on the internet. I see mash-ups all of the time. This book wasn't aimed at me. It was aimed at lawmakers, who don't have such an easy time hanging out on the internet. I hope that some of them read this book.

This book is about Lewis Carroll/Charles Dodgson as a mathematician. There were errors in the parts that I understood. So I didn't trust the other parts to help me to understand new stuff. Maybe I could have learned something about math if I'd tried harder. Or maybe I would have wasted time chasing my tail around the author's mistakes.

The book's intro points out some places where math came up in Carroll's kiddie lit. It's nice--but for this you of course want Gardner's annotated Alice books, which have the math-y stuff and the other stuff as well. Once you get past the introduction, the rest of the book is organized in fits, a nice Snarky tribute.

The first chapter fit is about Dodgson's childhood, concentrating on the math-y bits. He learned geometry. Good for him, I guess. The second chapter is about college life. He took exams. He did well at them. Good for him, I guess. In the third chapter, he's still an academic. He tries to teach some young kids math, tries using recreational math to keep them interested. The book seems to be looking up...

And then, there was the cipher. It was around here that I had a crisis of faith with this book.

...two days later, Dodgson recorded that he had devised another [cipher], far better than the last:

It has these advantages.
(1) The system is easily carried in the head.
(2) The key-word is the only thing necessarily kept secret.
(3) Even one knowing the system cannot possibly read the cipher without knowing the key-word.
(4) Even with the English to the cipher given, it is impossible to discover the key-word.

This new one was his matrix cipher, which is based on the following grid:

A	F	L	Q	W
B	G	M	R	X
C	H	N	S	Y
D	I/J	O	T	Z
E	K	P	U/V	*

...Following Dodgson, let us suppose that the keyword is GROUND, known only to the sender and receiver, and that the first word of our message is SEND.

• to encode the letter S we go from G (the first letter of the keyword) to S: this is 2 places to the right and 1 place down, and we encode S as 21;
• to encode the letter E we go from R (the next letter of the keyword) to E: this is 2 places to the right and 3 places down and we encode E as 23; ...

...and he finishes the example. I'm not a master of cryptography but when I look at this encoding scheme and look at the claim "Even with the English to the cipher given, it is impossible to discover the key-word", I call bullshit. Did Dodgson claim this? Was Dodgson wrong? That would be worth pointing out in the book--but that doesn't happen. Did the book explain the encoding scheme incorrectly, and maybe the real scheme really did have a way to keep folks from learning the key? Maybe.

A short while later, there's a sentence, in the context of Dodgson dispelling a rumor: "No British newspaper reports have been found that support Dodgson's account, so perhaps it was true after all..." This sentence--there were a few ways to interpret it, contradictory ways. Does he mean that British newspapers are unreliable so we should trust Dodgson? Does he mean that British newspapers are more reliable than Dodgson, so perhaps it (the rumor) was true after all? What is the author trying to tell me? Around here, I gave up on the book. I was just moving my eyes over the pages.

Maybe a good book to give to a budding nerd who liked the Alice books. On the other hand, you might do better to give that nerd The Annotated Alice.

I bought this book because its author is "Fran Lebowitz". This is not the same Fran Lebowitz who wrote the excellent Metropolitan Life and Social Studies. Rather, this is the "Fran Lebowitz" who usually calls herself Fran Rittman but whose maiden name was nevertheless on the cover of this book. Rittman is from New York, she smokes, she's a literary agent. The real Fran Lebowitz is from New York, smokes. I could kind of convince myself that maybe the real Fran Lebowitz became a literary agent. Rittman is a fitness nut, likes to run. The real Fran Lebowitz said that running was something one does to catch the bus. But she said that years ago, and I could convince myself that she'd changed her mind meanwhile. So I kept reading this book, hoping that it was written by Fran Lebowitz. You know, the real Fran Lebowitz. But the details kept on not fitting...

Fran Rittman wrote a memoir of being an ex-pat in Singapore. It was most interesting when I was interpreting it is the memoir of Fran Lebowitz having gone through many major life changes. That was especially interesting because I kept having to stretch further and further to make things fit. But once I admitted that things weren't fitting--that Rittman and the real Lebowitz were two separate people--this book was kinda dull.

Today I was that guy on the bus who wears too much scent. Not my fault! An automatic air freshener squirted me. Now I know why "fresh" can mean "offensive". I am very fresh right now, in that sense. Not like the "fresh" in "fresh content". That means "recent". Or as the cool kids call it these days, "real time". As of 7:33pm PDT 2009.08.18 I still smell like a stack of urinal mints, which means that this news is in "real time". This news is as fresh as I smell. You might even be reading it sooner than you would expect. Maybe. Depending on how often you check this stuff.

Blogger (the service which runs this here blog and many others) announced pubsubhubbub support. This means that after I post one of these blog posts, lots of services can find out really quickly. (Well, they could do that before, but it would have involved checking my website really often, which would have been silly, because I don't update that often. But now those services that want to check for recent updates can use one "hub" to keep up with many many web sites. So they can be really fast.) But I can keep writing really slow. Though with all of this "real time" stuff going on, I have to remind myself to maintain slack. That's right, I remembered the topic of this blog post. This is a book report, and it is on Slack. Not as in the stark fist of "Bob". I mean the book about managing software projects.

Slack takes a common-sense view, arguing against various software-development snake oil schemes. It was written back in 2001... so I'm reading it kind of late. I'm not keeping up with the literature in "real time," you see. So, I read about old snake oil. Some of that snake oil is still around, but it uses a different vocabulary now. Folks no longer strive for Quality. (That's Quality with a capital Q.) They do still pour effort into optimizing things that don't need optimizing, using this as an excuse to ignore harder problems. But they don't call that Quality anymore. And since they're looking for excuses to ignore common sense, they'll probably ignore the advice of this book. Oh, what? What's the advice? OK.

Don't work too hard all the time--you'll burn out. Besides, if you need to sprint for a while, you won't be able to speed up if you were already sprinting.

Make middle managers talk to each other, not just to their underlings and overlings. The underlings in group A and the underlings in group B might not be so great at talking to each other. It's good if their managers can talk every so often just to exchange ideas and news.

Oh, there's more but you're probably bored. It's all such sensible advice. Not like the snake oil. Snake oil is exciting, in much the same way that it's exciting to get squirted by an automatic air freshener.

Oh man I hope this stuff washes off.

This book is a novel. This book is about human evolution. No, wait, this book is about the evolution of society. No, wait, this book is about changes in society post-singularity. No, wait, this book is about the annihilation of society post-human. No, wait, this book is about the futility of consensus-based decision-making. No, wait, this book is a speculation on the paranoia of a eugenics-based society. No, wait, this book is a book about humans partially told from the point of view of an artificial intelligence. No, wait, this book is a spy thriller. No, wait,... this book is science fiction, but it dances around in many areas. It's a fun read, where by "fun" I mean bleak, cynical, yet interesting.

It's a novel by Aaron Cometbus! I hadn't heard it had been published until I entered a bunch of book ratings into Amazon.com. Amazon.com's recommendation engine recommended the book. Three cheers for recommendation engines. If you like Cometbus, you'll probably like this novel. If you don't know about Cometbus, this would be a difficult beginning.

Maybe I was fooled by the title, but this seems to be a story of people who have given things up. There is a straight-edge bartender. There is Aaron the musician known for touring whose favorite moments are when the band van breaks down. Characters break up relationships carefully, trying to improve themselves (and then thoughtlessly fall into other relationships). This makes for some fun musing, but this isn't really a book in which stuff happens.

There's stuff you do which you'd be better off not doing. Quit doing that for a little while and read this book instead. It will be so very appropriate.

This book is a sort of lexicon, except that instead of definitions there are riffs. These are some of the author's favorite words, or at least words that he wanted to write about. He likes to pronounce words, and reflects on words whose pronounciation seems to reflect their meaning.

This sounds like a self-indulgent book, but Roy Blount Jr wrote it, and it so happens that I am curious to know what Blount thinks about word sounds because he has a better writer's ear than I do. I care what he has to say about these words. He also writes about letters. He writes convincingly and charmingly about these words. Here's an example:

agenda Why is this a perjorative term? What's wrong with having an agenda? I wish to hell I had more of one. (Is that good English? "More of one?" I think it is, but it doesn't look printworthy.) Politicians play on the word's souding sort of dirty, like ...pudenda?

It comes from the Latin plural for "things to be done," but in English, it's singular.

He has some agendas himself. He just wishes you'd stop misusing just. He wishes you used literally to mean what it literally means. He argues his cases well. He's so convincing that he almost got me putting the hyphen back in e-mail before I realized what was happening. Keep your wits about you.

He cites dictionaries, friends, Yogi Berra, UrbanDictionary.com. The book, published in 2008, is already dated. He claims he googled [cancan "no panties"] and got no results. Today, there are about 150 though most of them, as you might expect, are not very interesting results, automatically-generated nonsense "dancing girls cancan no panties florida's top ten attractions" yeah whatever. He's aware of this advance of information. In the entry for "Google", he wonders "Has Google rounded up a googol of data bits yet? Depends on when you read this." (But he's exaggerating--there aren't a googol particles in the universe; storing a googol bits is thus technically difficult.) Blount is modern, of course. He outs himself as an UrbanDictionary contributor. (He has a feed, you can subscribe to it.)

(I should also point out: this book can go on for several paragraphs without mentioning pudenda or panties or a lack of panties. The book's not filthy. But it doesn't tiptoe around the dirt, either. That's a good thing--when this book says that the "buck" in "the buck stops here" doesn't refer to filthy bribe money, I believe it.)

So what you have here is a series of short essays in alphabetical order. Belles lettres? Sure. Great words, great words... "mnemonic" "Moebius statement" "monkeys". If you love words, this can be a slow book to read. Swann had his cookie; but words have associations, too. You can get lost in nostalgia. Like the entry for tallywacker. It's not enough to read Blount's opinion. I had to dig through my old comic books until I found issue #3 of "When My Brother Was God" so I could re-experience this quote, this rant by a dorm resident annoyed at what she hears through thin walls: "Mommy raised me a nice girl; I didn't go to twelve years of Catholic school simply to shout Jesus Christ his talleywhacker [sic] must be ripping out her esophagus at random intervals, oh no." The entries for tmesis and zeugma--each left me giddy. He mentions Morse (in the entry for wrought, and has entries for dash and dot.

He's not familiar with software development. He doesn't understand our sense of recursion, though he understands that he has used it to excess. (But, in his defense, who hasn't?) He mentions that weevil comes from the same root as "wave", which might suggest a naming convention to folks working on a certain software project but maybe it's a bit late to point it out. He has an entry for truthiness. I was talking with Matt L. at work about software development, about the demo that looks good, but has rickety underpinnings. Matt coined a term that needed coining, the software-scheduling equivalent of truthiness: done-iness. I guess my point is that we can't expect Blount to take care of everything for us.

But he does plenty. This book is a fun read; check it out.

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.)

This book is humongous! It's a survey of security computer engineering. It doesn't go into depth on any one topic, but it's got plenty of breadth. In areas where I already knew something, this book didn't teach me anything. But in areas where I didn't already know something, this book taught me plenty. For example:

• Some people are born without fingerprints.
• A history of smartcard hacking.
• The original motivator for "watermarking" schemes was for proof of authorship (but it turns out that folks aren't trying so hard to claim they wrote Miley Cyrus' songs--they just want to be able to copy those songs).

There were some aspects of Tor I hadn't heard about; admittedly that's because I don't know much about Tor. Similarly, I'd heard some things about government clearance levels, but I hadn't heard about some of the devices used to carefully, carefully move information betwen information clearance levels...

An interesting factoid from the more-exciting-than-it-looks world of banking: about 1% of bank employees "go bad" each year. Embezzles something, steals, helps someone else to defraud... One percent. That's worse than I expected. I don't think everyone is squeaky-clean, but we aren't talking about a random sample of the world population here. These are people who got hired at a bank. There was probably a background check somewhere in there. They had to make it through an interview with folks looking for twitchy behavior. They are monitored; they know they are monitored. I wasn't expecting that "go bad" rate to be zero, but... wow, one percent. Does that mean that anyone who's worked at a medium-to-large bank for a few years probably knows one person who's gone bad?

That was some of the interesting stuff in this book--looks at other worlds, not so far from web apps.

It's a big book. There's plenty in it. There's something to be said for a wide survey.

Angelenos worry about disaster a lot. At least that's the premise of Ecology of Fear. Los Angleles is prone to disaster, both in real life, in the movies, in books,... Maybe it's true. And yet. He cited many books showing how Los Angeles gets destroyed in popular culture plenty. He cited many books that I hadn't read. And he cited Dinner at Deviant's Palace, which I had read. Yes, this (pretty good) book takes place in a post-apocalypse L.A. But... the whole world of that story is post-apocalypse. The story just happens to take place in L.A. Oh, and I disagreed with his take on Bladerunner, too.

There was plenty of stuff in this book that wasn't about science fiction. He talks about earthquakes, fires, racial unrest. I just am familiar with the science fiction, I guess. And that makes me wonder how much he knows about the other stuff he writes about.

He's at his best when he writes about Angelenos' attitude towards risk. Shoddy buildings fall down in earthquakes, though everyone knows that there will be earthquakes. But people freak out when mountain lions attack, though those attacks are pretty darned rare.

And he convinced me that there are occasional tornados in Los Angeles.

Not his best book. I wish someone had warned me to skim parts that didn't seem relevant. Still, there were some good parts.

It's kind of a history of the oyster. It's kind of a history of shellfishing in New York City harbor. Once there were oysters. Then they were overfished. Then they were cultivated. Then water pollution came along, turning the oysters into disease vectors. It was OK. The book, I mean. The book was OK. The disease vectors were less than OK.

There's some interesting stuff in this book about scientific, medical, and engineering-testing uses of human cadavers. There's some interesting stuff, but there's some "humorous" reportage to slog through on the way there. The writer is working with interesting material--and she obviously did some good research to dig up this material and presents it well--but didn't seem to think that material was sufficiently interesting to her audience. So she tells us her reactions, she makes unfunny jokes, she tries to keep us engaged... I got tired of slogging through that. I stopped reading.

There were anecdotes of resurrectionists--graverobbers who didn't rob possessions, but who dug up bodies for early medical anatomists. There was a story I hadn't heard before: a guy running a boarding house who killed a sick boarder and then sold the body.

One thing I want to remember out of this book: I'd heard that crucified people couldn't breathe if they let themselves dangle, that they had to push themselves up or suffocate. According to one researcher, that theory was based on a kind of torture in which folks have their arms tied above them; but if your arms are out to the sides, you can still breathe OK.

I was a tourist in downtown Houston. I'd brought a couple of books with me--I finished those and left them behind. So now I had room in my bag for a new book. And I'd need a new book or else I'd have nothing to read on the airplane ride home, in spare touristy moments, etc. So I picked up A Feast for Crows, a book in the fantasy novel series "A Song of Ice and Fire" or whatever it's called. You may recall that I picked up another book in the series when I was travelling in New Zealand and... needed reading material because I'd read everything I'd brought with me.

It's a fun read! This series is still a good soap opera. The books are good enough such that "good airplane book" would be a backhanded compliment. They sprawl amongst many characters. The bad news is that means the book spends time on some characters I don't care about... but the good news is that there's still plenty of good stuff.

It's a book about cargo boxes. You know, intermodal freight containers. That was enough to get me to read the book. There's interesting stuff in here for economists, policy wonks, labor history folks, ... One thing that was missing was illustrations and photos--there are passing references to some physical designs for brackets, cranes, and joins that didn't work out. Oh well, what is in here is plenty interesting.

Regulation-haters will find plenty to point out here. Freight transport was covered with layers of regulation and protectionism. If you come up with a more efficient way to ship stuff, you might not be allowed to use it.

Some railroads sought to take advantage of the container not simply by lowering rates, but by changing the way they charged shippers. Since the onset of federal regulation in the 1880s, the Interstate Commerce Commission (ICC) had held firm to the principle that each commodity required its own rate, which of course was subject to ICC approval. With containers, though, the railroads were not handling commodities; the size and loaded weight of the container mattered far more than the contents. ... After four months of hearings in 1931, the commission ruled weight-based rates illegal. Although it found the container to be "a commendable piece of equipment," the commission said that the railroads could not charge less to carry a container than to carry the equivalent weight of the most expensive commodity inside the container. With that ruling, containers no longer made economic sense on the rails.

...

The ICC controlled almost every aspect of the business of common carriers--truckers whose services were on offer to the public. A common carrier could haul only commodities the ICC allowed it to haul, over ICC-approved routes, at ICC-approved rates. If a new firm wanted to begin service, of if an existing one wanted to serve a new route or carry a new commodity, it had to hire lawyers to plead its case at the commission. Any major change required hearings at which other truck lines and railroads had the opportunity to object.

In 1980, the ICC lost its rate-approval power, and things got smoother.

Shippers wanted to upgrade to use the new equipment, wanted to stop paying longshoremen. And few shippers wanted to share their savings with the longshoremen. This led to strikes. Those ports that got their act together early benefitted--because it turned out that the world didn't need as many ports in the container era. It took less time to load and unload ships, ships spent less time in ports, less ports were needed. Ports that deadlocked on their way to containerization lapsed into disuse. Previous labor wrangling had already led to bizarreness:

...a trucker delivering palletized cargo to a pier would have to remove each item from the pallet and place it on the dock. Longshoremen would then replace the items on the pallet for lowering into the hold, where other longshoremen would break down the pallet once more and stow each individual item&emdash;all at a cost so high that shippers knew not to send pallets in the first place.

When containers came along, the first reaction of some longshoremen was that there should be rules requiring that longshoremen unpack and re-pack each container. Before I read this book, I thought of Harry Bridges as heroic. Having read this book, I realize that I hadn't understood the scale of what he brought us. It's like he lifted us out of some kind of stone age.

Standards wonks might like the stories about how folks figured out which sizes of container to standardize on.

[Marad] voted unanimously that 8 feet should be the standard width, despite the fact that some European railroads could not carry loads wider than 7 feet; the committee would "have to be guided mainly by domestic requirements, with the hope that foreign practice would gradually conform to our standards."

So when I went to Japan and saw that they had smaller-sized cargo containers there, I shouldn't have been surprised. Determining standards for intermodal freight would affect maritime, rail, trucks--and these people weren't in the habit of talking to each other.

The history of shipping in SF bay shows up for a few paragraphs. how did Oakland get ahead of San Francisco?

Through the start of the 1960s, Oakland was a sleepy agricultural port one-third the size of Long Beach, Seattle, or Portland, and far smaller than San Francisco. Its waterfront was lined with industries&emdash;a dog food plant, a dry ice plant, a brake shoe factyory&emdash;that had long since ceased to be important port users. Oakland had almost no incoming traffic; typically, European ships would arrive at San Francisco, unload, and then sail across to Oakland to take on canned fruit, almonds, and walnuts for the voyage home. The Oakland Port Commission, a city agency, had issued its first revenue bonds in 1957 to repair a few old docks, but it had no grander plans. Then came an unexpected development. Officials in San Francisco, where Matson had based its container service to Hawaii, ignored Matson's request for a separate container terminal, because the city's port director through container shipping a passing fad. When Matson installed the world's first land-based container crane in 1959, it was built not in San Francisco, the West's greatest maritime center, but in Alameda, a small city within plain view of the Oakland docks.

Matson's operation focused the attention of Oakland port officials on container shipping. In early 1961, they learned of American-Hawaiian Steamship's application for government subsideies to build a fleet of large containerships. The vessels would run through the Panama Canal, mainly carrying fruit and vegetables from California canneries to East Coast markets. This was a natural cargo for Oakland to capture. Port director Dudley Frost and chief engineer Ben Nutter prepared two binders of facts and figures, added leather covers stamped "American-Hawaiian Steamship Company," and flew east in April 1961. Meetings with government and industry officials in Washington changed their plans. "Somebody said, 'Oh, forget those guys. They're no good. Go and see Sea-Land," Nutter recalled. "I said, 'Sea who?' " The cover on one of the binders was quickly replaced by one stamped "Sea-Land," and Frost and Nutter made their way to Port Newark. A Sea-Land executive stopped their presentation to inform them that it had already decided to run containerships from Newark to California. If they could offer a suitable site at a reasonable price, Sea-Land would establish its northern terminus at Oakland.

Oakland did more, too. They earned those At-At Walkers.

Part of the reason that Japanese electronics took off in the 70s? Because it was much harder for a shipping employee to filch small items from a cargo container, and cargo containers were on the rise in the 70s.

I learned a new shipping coinage. I'd already learned "Post-panamax", for cargo ships that are too big to fit through the Panama canal. "Malacca-max" is the author's word for a hypothetical cargo ship that's just barely big enough to fit through the Straits of Malacca. OK, I guess this book got kinda speculative towards the end. It's a fun read.

This book is subtitled "thirteen years in the life of an elephant family". It's by Cynthia Moss, who watched the elephants at what became Amboseli National Park north of Mt Kilimanjaro. The book reflects years of observations, many of them of the same elephants. Each chapter starts out as a slice of life in a family of elephants. There's a compelling soap-opera feel as characters recur. Not all of the book is told from the elephants' point of view. That's good--not too much conjecture sneaks into the slice-of-life parts, but some sneaks in. It's good that we also get to hear about the scientists observing the elephants, the things they see.

For the information architects, an excerpt about how they chose names for elephants:

Numbers would have been simplest, but experience had taught us that numbers were hard to remember once we had several hundred. "Now is she F 121 for F 132?"... We tried to choose common English and European names for the elephants because they were the easiest for us to remember. I am very thankful that we did so because today [late 1980s], with over 500 elephants named, it would have been very difficult to remember any obscure names. To this day I cannot remember who is who among four young males with Russian names in the "V" family. Vladimir, Vostok, Vasily, and Vronsky are forever confused in my mind and I always have to look them up before writing them down. Also, and this is a key, I was not the one who named them--they were named by colleagues later in the study. Naming is a fascinating phenomenon and a surprisingly powerful process. Somehow by naming something one possesses it, almost creates it. At the same time one feels a closer relationship to that thing. I did most of the naming in the early days of the study, but Harvey named a few of the animals, and although he has had little to do with the study in the last ten years I still think of Tania, Filippa, Justine, and Jezebel as "Harvey's elephants." When Filippa died in 1982 it was Harvey I thought of and wanted to call.

For fans of punch cards, an example of them being used in the wild:

Part of Joyce's work involved bringing the recognition file [i.e., notes by which an observer can figure out whether the elephant bull they're looking at is Vladimir versus Vasily versus...] for the bulls up to date. She took more photographs and worked with the photographs I had not yet sorted. I had devised a different filing system for the bulls from that of the cows, using a punched-card method. A friend, Chris Hillman, had used these cards in his study of eland and had suggested it might work well with elephants. Each card had 102 numbered holes running around the entire outer edge. I made a key, assigning various recognition factors to the numbers, such as "large hole in left ear," or "right tusk higher than left." Three of the holes indicated three general size classes of the bulls&emdash;young, medium, and large. Each bull's characteristics were assessed and the holes for these characteristics cut through on his card. Thus, out in the field, when I came across a medium-sized bull with a large V out of his right ear and a broken left tusk but I did not know who he was, I could take the stack of cards, run a spike through the hole for "V nick right," and all the cards for bulls with that characteristic would fall out from the bottom of the pack. I could then take those cards that had fallen out, run the spike through the hole for "right broken tusk," and more cards would fall out. If the number of cards that dropped down was still many, I could run the spike through the hole for medium-sized bull. By that time only a few cards would probably fall out and I could just quickly look through them.

This system worked well for the bulls because a bull could be anywhere and with anyone and thus there were no clues as to who he was other than his ears, tusks, and size. The cow pictures were pasted onto plain cards and carried in alphabetical order by their family. If one member of the family could be recognized, that provided a huge clue and the pictures of that family could be taken out of the file to compare the elephants present. Eventually we put the cows onto punched cards as well, and new researches used the system when they were first learning the elephants.

...so if you're writing elephant-recognition software, be aware: you'll want to use different signals depending on the elephant's gender. I love it when problems are more complicated than I thought--when I'm not trying to solve those problems.

The scientists see elephants in musth, and don't identify it at first. This seemed strange to me--I'd read a book from the 1930s whose author knew about musth. I mean, he didn't describe all of the symptoms--maybe because he was trying to spare the delicate sensibilities of his audience. But... folks obviously knew about it. Elephant handlers in Asia surely hadn't forgotten about musth. It turns out that folks knew that Asian elephant bulls went into musth. But they didn't recognize it in African elephants. One different thing about the African elephants--they tended to go into musth at, uhm, about the same time. At least, compared to Asian elephants, which were less synchronized. Thus, it was all too easy to think it was symptoms of some communicable disease spreading through the population.

A tale of controversy amongst the scientists:

When Iain Douglas-Hamilton did his study in Manyara he found that family units were remarkably stable in composition...

The results of an extensive radio-tracking study carried out in Zimbabwe by Rowan Martin called into question Iain's description of the degree of family-unit stability. Martin found that a female was rarely in a group of the same size or composition and that the most consistently stable association was between a female and her youngest offspring...

Fortunately, it turned out to be a case of no one being "wrong" but of elephants behaving differently under differing ecological conditions. In the early days of wildlife research many of the scientists were inflexible. If someone studied a species in one place and someone else got incompatible results in another place, it caused all sorts of anger and backbiting. It was almost as though each researcher thought his or her study animals displayed the Platonic ideal of the species' social behavior and thus anything that contradicted his or her description had to be wrong.

Ah, focusing on one detail and wrongly extrapolating to draw conclusions about the whole. She doesn't stoop to making a joke about the blind men and the elephant, so I guess I won't either.

This was a darned good book! I searched the internet for [cynthia moss] to see what the author was up to nowadays. It turns out that she's still associated with the Amboseli elephants--and even better, the folks watching those elephants have a blog! So I subscribed to the Amboseli Trust for Elephants blog, so I can catch up on the soap opera.

In this parallel-worlds scifi adventure, our hero meets some people who are largely, but not 100% like him; he figures they will all get along OK, and they do. He goes to strange places similar to our own world, but not quite like it. I read this book while riding a Greyhound bus through Texas; it all seemed to fit, somehow.

Fire Time is a science fiction novel from the early 70s. It brings you back to an earlier kind of science fiction. The author Poul Anderson drew out a solar system based on a trinary star. Then he thought about how life might evolve on one of the planets--sometimes it gets close to two stars instead of to just one. That's a hot time, a "Fire Time", if you will. All this against a space-operatic backdrop of interstellar war and diplomacy. Sketchy characters, long stretches of exposition (usually preceded by an apology), interesting science to think about. It's a darned fine airplane book--you can read it and enjoy it if you're not thinking too hard. I picked it up as a used cheap paperback, read it on a plane, and left it behind in Texas. I have no regrets.

I read this book because it was an Amazon recommendation, albeit a tepid one. Wow, what a great book! Remember Lynne Cox, the lady who swam to Antarctica? She wrote this book about a long swim off the coast around Catalina. Along the way, she runs into whales, a nice bait salesman, dolphins, life guards, anchovies, sunfish, and offshore oil platforms. There's stuff about gray whales, and where they fit in with other whales. There's stuff about training for long-distance swimming. There's stuff about the power of positive thinking... but not too much, fortunately, since I'm such a cynic. I've liked other things that Cox wrote about the feel of swimming in the ocean--observing the currents, the water, the life. This book pretty much all takes place in the water, and so there's plenty of that. It's a short book. If it were fiction, it would be a novella rather than a novel. It's a quick, fun read; check it out.

Amongst books set in the Lovecraftian "Mythos" universe, this is the best I've read so far. That's kind of a backhanded compliment. I dislike H.P. Lovecraft's Mythos books. I suppose it's guilt by association, but I dislike the Mythos universe so much that I occasionally go back to the Temple ov thee Lemur's War in Heaven just so that I can vote against the Mythos deities a few times. Yeah, so, backhanded compliment. But it is a compliment, and I enjoyed reading this book. It's set in a strange future in which humanity has traveled to distant stars but Baskin-Robbins and Applebee's still exist. There is also a musical play called "Dating the Volcano God", which begs the question of which Dead Milkmen song would be most apropriate here: Born to Love Volcanoes? or The Fez?

This book has everything: wizardry, parallel worlds, lizard men, a dragon, ogres, magical swords, a flying saucer, romance, court intrigue, an armored personnel carrier, death scenes, a dude who was raised by wolves, ... It was a fine book to pick up as a dollar paperback. It was light and cheap; I was not encumbered when I brought it to Houston. It entertained me. I left it in Houston with no regrets after I finished reading it. Part of the plot involves US soldiers parallel-worldlishly transported to a fantasy world. They help save the world. Well, that world, anyhow. I expected this to be a bigger part of the book--hey, here are some characters I can identify with more easily than these princes, wizards, and such. But strangely, they're pulled in... and don't do that much, plot-wise.

This book, written by PR consultants tells you why your business is spending too much money on advertising and should spend money on PR instead.

Advertising lacks credibility. E.g., when I see an oil company billboard advertising their nature-loving 'green" activities, that doesn't convince me of much. Advertising does OK at reminding me that those companies exist, though.

This book's thesis is that if you have a new story to tell, you want to use P.R. There are journalists out there looking for new stories. They'd love to hear from you about your new whatsit.

But if you try to use advertising, then (a) you're telling people something new via a medium that they don't trust--they won't trust your story; (b) you're no longer "news" that a journalist can report--why bother to report something that's being advertised widely? So you won't get P.R.-ish publicity.

This book doesn't point out P.R.'s own credibility problems. Plenty of P.R. channels are losing credibility, too. Nowadays, a trusted news outlet is one that warns you where its message is coming from--investigative journalism involving checking more than one source is pretty sparse.

They also don't talk about highly-directed advertising; their criticism is for mass advertising. It's not clear what they think about, say, showing ads for fishing lures on Google searches for [trout]. (But this book was written back in 2002, so I guess that's excusable)

Before I launch into a complain-y whine about a book, I want to remind myself that there are good things in life. Yesterday was a good day. (I didn't even have to use my A.K.) There were good comics at the comic book store: Phonogram, Castle Waiting, The Boys, and a new-to-me League of Extraordinary Gentlemen (but apparently it's been out long enough for Jess Nevins to annotate, so I could just enjoy all the references without having to hunt them down). At the Ferry Building, I thought I was just stopping off for bread and coffee, but saw clumps of folks clutching orange pieces of paper and running around looking intently for something. I shadowed some of them and it quickly became obvious that these folks were playing in the Great Urban Race. One pair of them let me look at their question sheet in exchange for directions--it made me glad I wasn't playing. Lots of trivia, a substitution cipher--tangentially close to my thing, but not my thing. But after I'd finished drinking my coffee, I ran into Joe Fendel, who was playing, plus his brother. Then on the subway ride home, I ran into Bryan Clair's parents, and we chatted a bit. Living in a big city, you don't really expect to run into people you know, but it's fun when it happens. At home I took care of some errands, so I even felt kind of productive. So, those are good things.

Anyhow, book report. Anyhow, Un Lun Dun. Yeah.

This book, about a girl who is swept up in a world of horrific adventure in a not-quite-London which exists parallel to real-London, is nevertheless not Neil Gaiman's Neverwhere. It's better than Neverwhere was. But I'm nevertheless not willing to forgive it for being another book about a girl who is swept up in a world of horrific adventure in a not-quite-London which exists parallel to real-London.

I read this book years ago, but I read it again more recently. It was on sale as a tiny paperback. Sometimes it's useful to have a pocket book that, you know, fits in your pocket. That way you can still bring something to read with you even if you don't want to lug around your manpurs^W backpack. So I picked up this book and I read it. It was good!

It's a sequel in Robert Aspirin's Myth series. In this episode, our hero Skeeve grows up, takes responsibility for his actions, and thus becomes a better leader. Yes, this is a magical fantasy book with wizards and trolls and such. And yet, in this book, the protagonist succeeds by becoming more mature. This book was probably sneakily educational the first time I read it.

This book is about changing a company's culture. It's about Microsoft. It's about Gates and Ballmer shifting the company's culture as they had to comply with the various legal judgments against the company.

According to this book, the original Microsoft culture was based on winning by any means necessary. I don't think that's true. I think that Microsofties with that attitude made many important industry-changing decisions. I think that Microsofties with that attitude made illegal deals with OEMs that abused monopoly power and sank a company I worked for. I'm not denying that such an attitude existed within parts of Microsoft. But I don't think that attitude permeated the company as this book would have me think. I've met too many Microsofties and ex-Microsofties who were happy to win by, you know, creating products that customers wanted.

Anyhow, this book is about how Gates and Ballmer decided to mature Microsoft out of this win-by-any-means-necessary attitude towards another model, a model that would be more stable, more appropriate for a large company. Listening to customers instead of cramming new versions down their throats. To make this attitude shift, Gates had to retire from the CEO position, no-one was going to believe him as the bearer of "nice-guy" guidance. So Ballmer had to step in, because it required a new face to deliver such a new message. And...

Wow, did it really require a massive shift in the company to get people to stop making illegal deals?

This book is based on interviews with high-level executives at Microsoft. I wonder if the "Let's abuse our monopoly powers" attitude was prevalent at the executive level. Maybe the executives thus assumed that this attitude was company-wide? And so they thought they had to totally shake up the company?

George "Slim" Lewis was an animal trainer in the depression-era USA. He rode the rails from circus to circus, handling elephants. He specialized in unruly elephants. Thus, this book has a "thriller" aspect to it. You're reading along and every so often, someone gets swatted across a room. Or gored by tusks. Or crushed against a wall. Or sat on--sat on really, really hard. This book reminds you that elephants are not always nice, and that they are tremendous.

It's a tough book to read if you like animals. Back in those days, it was accepted practice to use an elephant hook. (I guess this is the same thing as an ankus.) It's difficult to read a narrated description of giving an elephant a shallow cut that will take days to heal. This man--he feels affection for elephants, he just learned that cutting them was a way to get their attention & respect in a hurry. He sticks by elephants when various zookeepers and entertainment industry promoters are ready to kill and/or abandon them. Elephants had it rough in this country.

There are stories about elephants, about circus life. I learned that "The Greatest Show on Earth" earned its title--at least it had an order of magnitude more elephants than most circuses did. There were also glimpses of life at some of the smaller circuses, and some of the strange politics around city zoos.

This book is set in a parallel universe. In this universe, mad science reigns. People care about literature! There are vampires! It's all different from our universe! And yet somehow similar!

You'd think I would love this. Yet, I did not love this.

People talk about a concept called the "uncanny valley". It comes up when you try to make things that are like people. Like if you try to make an android. Or if you write a computer program that tries to hold a conversation over IM chat. If you make something that looks totally like a machine, people interact with it neutrally, as if it were a tool. If you slap a cartoonish smiley face on it, people react to the thing positively. People like cartoony things. If you make it seem a little more human, people react to it more warmly. But... if you create something that seems almost human but not quite, then people react against it strongly.

I want to propose a new concept, the "unsilly valley". This refers to a work of art that approaches the absurd, does not quite achieve it, and is thus trapped in a strange zone: too strange to inform, too normal to be interesting.

I think The Eyre Affair falls in this zone.

It's a popular book. I suspect it's popular with people who like the idea of an alternate universe in which more people care about literature. But in the book's world, Dickens is an example of stuff worth caring about. C'mon, really, Dickens? I can only suspend my disbelief so far.

I'd heard that William Gibson had written Pattern Recognition, this book that wasn't science fiction. So I didn't read it. That was years ago.

More recently, I read Spook Country that wasn't exactly science fiction. It had some science-fictiony elements, but they were just a few years out. I'd been tricked into reading non-science fiction by an author I thought of as locked in a genre! But I'd liked it anyhow. So I gave Pattern Recognition a try. OMG, it is awesome! It is better than science fiction--like Douglas Coupland, Gibson has teased out some aspects of real life which are even better than science fiction.

• signals intelligence
• historical computing devices
  • Curta!
• the decline of undirected brand-based advertising
• the rise of astroturfy viral marketing
• did I mention Curta?

Oh yeah--and there's a plot and characters and plenty of references to pattern recognition, both as it relates to signals intelligence and to other things. So you can feel all brainy and literary as you read along and pick up on allusions and tsk at characters who make bad decisions.

It's a collection of essays, not in any particular field. Apparently essayists, when they aren't writing about something in particular--uhm, apparently, they tend to write about themselves. Or else the editor of this collection likes that sort of thing. There were a bunch of slice-of-life-ish autobio pieces in here. "Personal essays" might be the phrase I'm looking for. I like autobiography and slice-of-life bits just fine... but the authors of these pieces weren't grizzled adventurers living lives of derring-do. They were, uhm, essayists: authors, college professors. I didn't finish reading some of these.

Getting past the griping, I liked a few of these essays nonetheless. Emily Bernard's "Teaching the N-Word" explores language, racism, and culture. Susan Orlean's "Lost Dog" was a good story, but it was a good story back when I first read it in The New Yorker, too. "George", by Sam Pickering, was good, but sad. "Group Grief" by Lily Tuck was good, but sad. It's good that these authors are able to find a silver lining in their tragic lives by using them as material for essays.

Still, I don't just want to read sad slices of life. Not too many in a row, anyhow. Especially when they're lives of bookish folks; those strike kind of close to home.

I read this book because it's by Dorothy Bryant who wrote the excellent The Confessions of Madame Psyche. I read it even though my mom read it and didn't care for it much. I didn't care for it much. In the book, the protagonist dies and goes to another world. Unlike John Carter of Mars, when he dies he doesn't go to a world of action and adventure. Instead he goes to a world where people live communally and simply and achieve enlightenment by paying attention to their dreams and....

This book is copyright 1971. It was a time when some people were trying to strip away the bullshit of materialistic consumer-ish lives. That's a good thing. But finding a compelling narrative underneath all that... it ain't easy. I'm not saying that I could do it better than Dorothy Bryant did. I'm just sayin' it ain't easy, and I don't think it happened here.

Non-programmers might not realize it, but some computer program source code is even harder to read than the rest. Some of this code is so messy that an experienced programmer looks at it and says "I have no idea what is going on here. Maybe I could figure it out, but... what's on TV?" This book talks about some general principles of writing readable code; and there are examples to illustrate good and bad code.

This book is from the 1970s. The examples are in the FORTRAN and PL/I programming languages. They are in an old FORTRAN--I think FORTRAN has changed a bit since then. I think this book uses an old dialect. I'm not really sure, though. I don't know FORTRAN nor do I know PL/I. Actually, that was a problem with this book. The book had "before" and "after" examples to show how to "clean up" code to make it more readable. I couldn't always understand the "after" examples. Well, I could, but only after the head-scratching I associate with my attempts to read poorly-written code. For example, DO 2 I=1,N After looking at some other examples, I think that means "Loop N times over the block of code that starts here and ends with the line of code labeled "2".

As it was... I think this book might be of more interest to the historian than to the programmer.

I picked up this book because I'd heard it talked about codes and also about digital circuit design, two topics dear to my heart. I started on it and it seemed pretty readable. But it stayed with pretty introductory material, at least for the first several chapters. And when I riffled the pages of the rest, it looked like I wasn't going to learn much. So I put it down. Still, if this book had been available twenty years ago, I would have been glad to read it. (Except... I'm not sure if I'd discovered the fun of reading non-fiction back then. Uhm, if this book at been available twenty years ago and I'd been wise enough to appreciate it and, uhm... now I forget what the question was.)

This book is about negotiating agreements. You want mushroom pizza, they want bell pepper pizza, how do you figure out what to do? You look for middle ground, of course, and this book talks some about how to do this.

Perhaps more usefully, it talks about how to deal with people who want to "win" a negotiation. When I'm faced with high-pressure sales tactics, I just walk away. So far, that's been pretty easy--there's always been other places to go.

Ah, memories...

"Hi, I'm thinking of buying a pool table. Right now, I'm just calling around to find out about prices. I'm interested in blah blah blah describing specs blah blah blah. What would you charge for something like that?"

"$2300 if you order today."

I never called that place back. Maybe I should have once I got prices from other places. Maybe they would have negotiated; I never gave them a chance. This book talks about some ways that you can get past the high-pressure negotiating tactics to something more useful. If you're dealing with a professional salesperson, it might be as easy as asking them to stop.

• Don't just ask for their position--ask them the reasoning behind their position.
• When they tell you things, listen. Don't get distracted thinking of what you're going to say next.
• Ask them if you understand them correctly--re-state their position.
• Tell them the reasoning behind your position. That might suggest some negotiation wiggle-room to them.

It's all good advice. I think most folks tend to do this anyhow. But it helps to spell out the steps--especially when you're dealing with sonmeone who isn't inclined to be so reasonable.

This book is about web usability. It's kinda old, from the year 2000.

Reading it with this historical hindsight was somewhat discouraging. Apparently, webmasters have made the same mistakes for several years.

I've "used" Oracle applications. When I say "used", I mean "tried and gave up". Oracle calendar was slow, buggy, and thought it was a good idea to store my password, unencrypted, in a publically visible file. Yes, I'm still angry about that. Oracle expense report software has saved my employers plenty of money. Not because it's efficient. Rather, because it's so awful that I tend to pay for things out of my own pocket rather than try to file expense reports.

The Difference Between God and Larry Ellison is a history of Oracle Corporation and CEO Larry Ellison. Oracle got ahead through selling vaporware and spreading FUD. I always assumed that their apps were crap but that their underlying database must be good--because they were a successful database company, right? But it turns out that they were in the right time and right place. And they won and kept a lot of business by lying to their customers.

This book was a powerful reminder that a company can do very well by cheating its customers and doing evil. I like being honest with customers and like finding "win-win" situations... but there are people who say "screw that" and go for the quick bucks. If I assume that a company that's been around for several years must have some kind of honesty or else their reputation would have caught up with them, Oracle proves me wrong. I guess I shouldn't have needed this book to remind me. There are plenty of long-lived evil companies out there.

This sci-fi book, dedicated to Heinlein, features an android female sexbot who-- Hey, wait, come back! You're thinking that the book is going to be some awful misogynistic piece of crap. But it's not (albeit in the opinion of me, a patriarchal male oppressor). The book takes place after the human race has died out, leaving behind many, many robots. Some of these robots, e.g., miners, still have a purpose in life. The sexbots, on the other hand, have not had it so easy--they had to find something else to do. This book has farce, intrigue, and a lemur. Check it out.

This is an old textbook about applying cryptography; that is, it's about computer security. It's the textbook by Bruce Schneier, the book he later said wasn't so important--you can get this stuff right and your system still might not be secure. Your fancy security system might not do much good if everyone in your company's art department thinks its easier to trade passwords than to set up a shared file server. But I read it anyhow--some pieces of security still seem useful.

It's an old book; people crack codes over time. This led to some disappointment while reading. I got kind of excited to read about FAPKC, a Chinese cryptography system based on cellular automata. This was cool on a number of levels, and not just because it evoked a puzzle from the No More Secrets game. But it turns out that FAPKC was broken back in 1995--probably at around the time this book was slogging through the book publishing process.

I'm glad I read this book; this book made me think. It's not just about the crypto; it's also about protocols built up from crypto. Suppose you have a way to encrypt messages, a way to sign messages. How do you exchange data with someone without being eavesdropped upon if you haven't already exchanged keys with them? OK, you've probably already stumbled into key-exchange protocols. But there are weirder things out there. This book talks about several of them--including how some protocols were found vulnerable. It's good exercise to think about these things, try to figure out how you would crack them. I didn't always succeed. There's another good lesson there--sometimes you can look at a broken system and think "well, it looks OK to me". Trust no-one, least of all yourself. This book had plenty of good puzzles dressed up as protocols.

There was a quick run-through of useful mathematics. This was a nice refresher for stuff I already knew. For the stuff I didn't know--number theory--this wasn't enough to teach me much. But there were references to books with more information with some recommendations, so there's hope for the future. And of course there's still plenty here that you can understand even without the number theory background. The book wants to be both a reference and a lesson-book. Nowadays, for the reference stuff, you'd probably search the web instead; in hindsight, it would have been nice if the book had concentrated on the lessons. Still, it's a fun read; check it out.

Happy National Poetry Month! To celebrate, this blog post contains no poetry. You're welcome.

The Mote in God's Eye is a science fiction classic that I never got around to reading. Except that I finally got around to reading it. It was OK, as long as you didn't think through the premise very thoroughly. It's a first contact novel. The humans are a star-faring empire. They encounter the Moties, a species of alien with many specialized sub-species. The Moties have only ever been in one star system, because they [censored to avoid SPOILER, also thus concealing the not-so-believable premise]. The Moties have three hands, thus explaining some geek jokes. I guess that sums up why I stuck with reading this book. The characters seem pretty cardboardish. The premise leaves the audience going oh come on. But it was a quick read and now I understand some cultural allusions.

This is a book about business, yet it's a good book. It's Howard Jonas' autobiography. He starts out operating a hot-dog pushcart. He moves on to distributing those tourism brochures you see in hotel lobbies. He starts doing a variety of mail-order business. He becomes a telecom mogul. Whoa--that's a leap.

Along the way, you learn about his principles. This is good; he has some principles that I disagree with, but he states them well. It's good to have articulate people to disagree with--they're the ones you're most likely to learn from.

long the way, you see places where he's had to compromise his principles--those are pretty educational, too. And that reminds you that these principles are, uhm, tempered by experience and stuff.

There's a temptation to make a joke about "how the sausage is made", but he doesn't talk about how hot dogs are made. He does give some hints about how to make some superior onions for hot dogs, though.

For example, early on he talks about how he took on a manager to help run a small business. He spotted someone running a deli and thought that someone who could manage a deli could manage just about anything. (I'm oversimplifying, but you get the idea.) I threw a nerd hissyfit. I'm soooo tired of the MBA attitude that someone who can manage something can manage anything. But But Jonas then goes on to point out that this management-skill-transferability... he points out that it doesn't transfer so well for technical teams. Which would explain a few things. It would explain why my past experience on technical teams dealing with managers... uhm, managers best suited to running delicatessens... it would explain why that experience has been poor. But the idea that the transferability works well outside technical fields--that would also explain why the MBAs keep suggesting that it would work well.

It's a good book. It has some good jokes, too. Check it out.

I guess I made through ~100 pages of palace intrigue before I realized I don't especially want to read through that much palace intrigue. Yeah, that's right, I'm yet another person who made it partway through Decline and Fall of the Roman Empire and then wimped out.

I'm a professional technical writer and I recommend this book about writing: Letting Go of the Words. I theoretically train engineers so that they can write clearly. This book would help those people--will help those people. I'm going recommend it. (Brief pause to log on to work and recommend the book on my internal blog-equivalent... Ah, thank you for your patience.) I don't tend to recommend writing books to engineers. Just The Elements of Style sometimes, but that book doesn't address the problems most of these geniuses have when writing.

I work with a bunch of web programmers. They might be confused by some chapters of this book, chapters which talk more about usability issues than about word choice. Protip: some of the same goofs that can make a web page unusable can make a web page's words unreadable.

But there are chapters about word choice, too. And about keeping your audience in mind, and figuring out what they're trying to do, and helping them to do that.

Of course, plenty of this stuff is controversial--amongst technical writers, who are detail-oriented folks who tend to bicker over minutiae. Maybe I like this book because I largely agree with its point of view. I'm sure that some of my colleagues would consider it harmful. (OMG a quick overview blurb before the three paragraphs of background material necessary to truly understand that blurb!!?! Yeah, I'll burn in hell for that by some standards--but maybe I'll let folks know whether it's worth their time slogging through those three paragraphs, spare some of those people the trouble.) Maybe I should ask other writers what books they recommend, make sure I'm listening to other points of view. But it took me so long to find a book that I'd recommend, I just kinda assumed none of them had a book that they recommended. I learned my craft in the school of hard knocks, didn't everyone?

Anyhow, I'm excited. So yay.

I'm taking the day off work today. It's the day after a Bay Area Night Game (a rather-fun instance thereof). It was one of those Bay Area Night Games that actually happens at night, and thus I was up way past my bedtime last night. But I was prepared! As a veteran of these games, I've learned an important night game technique: schedule a vacation day for the day after.

Today I slept in. And I made it to the kinda-newly-opened California Academy of Sciences. This was my first time seeing the place since it re-opened. There was new stuff to see--the rain forest exhibit is pretty darned nice; not as impressive as the Eden Project, say, but much much easier to reach from my apartment. There's a big penguin display. There were "old friends" to look at, too: the pendulum, the alligator pit. I was sad to see that the two-headed gopher snake had died, but honestly it wasn't especially active back when it was alive.

I was bumbling around, not paying much attention to some taxiderm-ified bear, except that I noticed "Monarch". This was a locally-famous bear&emdash;famous as a publicity stunt by Hearst, the newspaper magnate. It's a sad story--Hearst hired a hunter to bring a live bear back to the city. The bear, named "Monarch", lived the rest of his life in captivity; but the local zoo didn't want him, so he was just in some cage in Golden Gate Park. His image appeared on the papers; the Examiner was "The Monarch of the Dailies". His image also appeared on the California flag--I guess if you're a flag designer who needs some bear, art, it's handy to have a captive grizzly to look at. Too bad that the California grizzlies were going extinct around this time. (You can call up the museum's phone-based interpretive text for Monarch: 1-415-294-3602, then enter 6#)

Why did I have this bit of San Francisco history rattling around in my head? A few months ago, I read Gaudy Century, a book of anecdotes and maybe-history of San Francisco newspapers.

Newspapers are in trouble these days, but newspapers have always been in trouble. This book is full of tales of newspapers going under. Most newspapers started up without a business plan more sophisticated than that of the Underpants Gnomes.

There has been much tearing of hair and gnashing of teeth over the ongoing collapse of newspapers. Sure, there are blogs--but those don't have armies of fact-checkers. Then again, newspapers get things wrong. If you've ever seen a Real Journalism article about something where you know the facts--at first, it can be jarring when you see how far off they are from the facts.

Gaudy Century is a book on the history of San Francisco newspapers. It was written by John Bruce, an editor of the Chronicle. I guess it's riddled with errors. Unlike a blog with a nice comments system which allows feedback from around the world, this was a physical book. Thus, the only errors I know about are those that inspired previous readers of this library book to scribble in the margins--or those which triggered my b---s--- alarm and prompted me to look things up.

This book claims that the first newspaper for "negroes" was published in San Francisco. There's no detail backing up this claim; The relevant Wikipedia article on "African American newspapers" disagrees and cites sources. What made Bruce so sure that San Francisco was first? We'll never know; he doesn't tell us.

A few pages later, book says "The People's Party won [the San Francisco city election] with a scant margin." Someone underlined that "scant" and wrote "Check your facts, Bruce!" out in the margin.

Later on, he claimed that the term "hoodlums" originated in San Francisco. I looked that one up--and folks agree with him there. But it's not a good sign when the reader's tempted to double-check claims because "I bet I could fact-check this with a simple web search for [etymology hoodlum]" rather than because "This is an especially outrageous claim."

I ended up treating this book as a book of local myths and legends. Seen that way, it has some good yarns. Maybe Hearst was exciting. Maybe the de Youngs were murderous. Maybe some things in this book were true; or maybe they're better than that.

Here's a strange thing about newspapers: it seems that plenty of them were founded hoping to sway personal opinion. This whole teetering-on-the-edge of economic collapse seems familiar because most of these newspapers weren't started up with sound business plans--they were trying to get people to read, but were harvesting minds, not dollars. That is, they'd present reports of current events, financed by advertising, hoping that folks would adopt the opinions of the editors. Why didn't they just publish their opinions? Of those who wanted to spread their opinions, why did so many choose news reports as the, uhm, hook? Why not, say, recipes?

Growing up, I wasn't too excited about newspapers. Reading this book--I guess maybe my lack of excitement might be because the San Francisco papers were relatively weak-sauce. I hope that some medium emerges that serves investigative reporters well; or if not "well", at least better than newspapers have. And ideally that medium would allow for reader comments--if the margins of this book, are any indication, it's useful to let your readers check your facts.

Just hours left until BANG XX. Can I claim that this is an appropriate time for a book report for a book that has 20 in its title? It's my blog; I can claim anything.

The First $20 Million is Always the Hardest: A fun fluffy novel set in Silicon Valley. I sure hope that these characters were exaggerated for comedic effect. The characters in this book seem even more warped than the nerds I deal with on a daily basis. There is something to be said for fun fluffy novels.

Some might say it's been too hectic of a week for me to post a book report, but prepare to be amazed at my review of The Lord of Castle Black:

Swashbuckling swords and sorcery.

It's a collection of essays by Brian Hayes--the guy whose magazine article got me into Markov Chain-generated English drivel. I was able to follow most of these essays, which was darned nice since I'm not a math guru.

• Clock of Ages Thinking about the Long Now Foundation and related topics. He points out that it would make sense for the Clock of the Long Now to be associated with a nuclear waste site--if you're going to go to the trouble to set up an institution to last 10000 years, maybe that's what you need to warn other folks away from something that's going to stay toxic for 10000 years. I thought that was my idea. But then I saw it in Anathem, and a few days later I saw it again here. I guess the Long Now Foundation was in the news at the same time as Yucca Flats and Carlsbad. Maybe plenty of geeks were thinking the same way.
• Inventing the Genetic Code Some mistteps along the way, explained. I couldn't follow much of this.
• Statistics of Deadly Quarrels What happens when a statistician tries to count up casualties in brawls, border conflicts, battles, and world-ranging total wars. Lewis Fry Richardson tried to do this. It's not easy. Everyone lies about casualty counts. It's sometimes difficult to figure out where one war ends and the next squabble begins.
• Dividing the Continent How would you algorithmically determine the contiental divide of a 2-D surface in 3-D?
• On the Teeth of Wheels An introduction to clockwork computing. If you have a clock and you want it to do something once every N ticks, you might set up a gear wheel with N teeth to do something once per rotation. But what if N is large, so that you can't fit that many teeth on a wheel? Then you might set up a few wheels in different numbers of teeth, some attached at the axle, some with interlocking teeth. And you'd learn a lot about factoring.
• Naming Names Namespaces, hashing
• Group Theory in the Bedroom Considering mattress-flipping as a series of mathematical procedures and as a documentation problem.

There were more essays than just those, too.

It's a bunch of essays by Paul Graham about software development and other kinds of development. Some of these essays are interesting, some are irritating. They're interesting because Paul has a well-spoken, cranky take on many topics. They're irritating because he attributes his opinions to all computers geeks. "We hackers know this." "We hackers think that." There were plenty of times when I thought "I agree with this sentiment", but there were also plenty of times when I thought "What do you mean 'we'?"

I don't believe in absolute Quality with a capital Q. I don't believe it's the genius of creative people is to discern that Quality. If I wanted to read about Quality, I could go read Zen and the Art of Motorcycle maintenance. In that book, the Quality-delusion is attributed to an insane person, not to me. Thus, Zen and the Art of Motorcycle Maintenance is less irritating than Hackers and Painters. I'm not a Libertarian. I'm not. I'm glad that other languages have stolen cool features from LISP, but I don't especially want to code in LISP ever again. There are plenty of places where foreach makes more sense than recursion does; I'm glad your language is optimized to not blow stack on tail recursion, but if your language supported a foreach loop, you wouldn't have to worry about that @^*% in the first place.

Now that I go back and flip through the book, looking for something nice to say about it, I keep thinking "Oh, this was just a rant" and "Someone else said it better". So I'm not sure what good things I can say about the book--which is strange because I did enjoy reading it. I guess I enjoyed it because it touches on topics that interest me.

A fun piece of cyberpunky science fiction. Where by "fun... cyberpunky", I of course mean cynical and bleak. Personalities can be placed into new bodies. Criminals are punished by going into forced hibernation, during with other folks might be able to use their bodies. Some people are unbelievably old and jaded. It's a world of miracles, but these miracles have brought no joy.

A series of musings about how people really behave. Or, rather, how they misbehave. Describes experiments about placebos, cheating, and other circumstances in which people lie to themselves and to others. I'd heard about some of these topics. Lately, some economists have pointed out how people don't follow the simple economic model--that people follow other rules, similarly predictable albeit less sensible.

But there were new-to-me ideas in this book. E.g., that to encourage people to be honorable, you might occasionally ask them to swear an oath to be honorable. Not necessarily because you expect them to respect the force behind that oath, but instead to remind them that honor is important, to remind them that they think of themselves as honorable, that they take pride in it.

An introduction to layout design. There are general principles; there was also more detailed advice on designing brochures, business cards, and other stuff I don't care about. But the general principles seem like stuff I could apply.

• Proximity Keep related things together
• Alignment Create strong lines through alignment. Use alignment to "connect" far-apart page elements.
• Repetition Re-use elements
• Contrast Why use a small difference when you can use a big one?

Families of type. Don't use two typefaces from the same family--they'll be similar enough such that they won't work for contrast. That rule of thumb of using sans-serif vs. serif for headers vs. body text comes from this general principle.

• Oldstyle Times, Palatino, Baskerville, Garamond
• Modern radical thick/thin transitions more likely to hit at 90deg than at the slanty-pen Oldstyle look. Bodoni, Times Bold
• Slab serif Thicker lines. Clarendon, Memphis, New Century Schoolbook. Readable for extensive text, but they make the page look dark.
• Sans serif Be careful with varying-weight fonts like Optima--they don't combine well with other sans-serif, but also don't combine well with serif fonts
• Script
• Decorative

This book is about hacking online games. Unfortunately, they started out talking about plenty of stuff which I already had read about. Cheating happens. E.g., people in shoot-em-up games use video drivers that don't fill in the walls, just draw "wire frames"--and thus they can see bad guys through walls. Stuff like that. The economics of MMORPGs, of selling stuff. I guess I heard about this stuff from Slashdot and comp.risks? I dunno. By the time they actually start talking about how to exploit games, I wasn't paying attention any more. And it seems like they assume you have access to some software library that only they have access to? Maybe if I'd kept paying attention, I would have learned some things about reverse-engineering.

This is a book about running small businesses. The title says "growing", but it might as well have said "evolving". Hawken is thoughtful and wise, reminding the reader not to take on too many problems at once, to treat people well, to... I'm not running a small business, but there was still some good advice in here, a lot of it is about running your life.

Yestere'en, I watched the Chinese New Year's parade. I'm not into parades, but I visit a fair number of parades. Why show up an event I'm not into? A non-trivial fraction of my friends are photographers; they like to photograph parades; I like to hang out with my friends; thus my attendance logically follows. I'm not a photographer but I need something to keep me busy at these things. A few years ago, I started waving.

People in parades wave at the crowd. People on floats wave. Politicians riding in open-top convertibles wave. Beauty queens wave demurely. Banner-carriers wave. Small children, stumbling along in procession, wave adorably. Their parents, walking alongside, wave proudly. Sometimes, a few folks in the audience wave back. I always wave back. I smile and wave. Parade traffic is bursty; sometimes the parade stalls. Most folks in the audience who wave back at the parade stop waving when this happens; it's not easy to keep waving that long. Also, it's kind of awkward to keep waving at the same set of folks for a long time. I keep waving. I'm no stranger to awkwardness. A few years back, I wouldn't keep waving--I didn't have the endurance to keep going. But I got better, you know?

I kept practicing, parade after parade, year after year. I learned how to wave so that it's not so tiring. I learned a few different ways to wave; by "mixing it up," I can avoid straining my shoulder. At first my friends were embarrassed to be next to the big goofy waving guy. But there are advantages. Peter Tang, reviewing his photos from last night, pointed out that he got pretty good photos of the beauty queens, getting good shots of their faces. "They kept looking right at us--because you kept waving."

Gavin Newsom, mayor of San Francisco pointed me out last night: "He's got the wave down." Gavin Newsom, has marched in plenty of parades and has no doubt seen plenty of wavers. I don't agree with Newsom on many things, but I trust his judgment in this regard.

Late in the parade, the audience had thinned out. And most of the audience that was still there was tiring out. But I was still going, still waving, unflappable. A girl in the parade yelled at me: "Hey, you! You're the only one waving!" I'm not sure if she meant it as a compliment, but by golly I was pleased that I was still strong enough to maintain unwavering waving.

After the parade, I still had some strength left in my arms. I realized that I could have kept going. I'd only waved back at folks who'd waved. But now I thought: Next year, could I keep waving through the whole parade? This would involve waving at folks who wouldn't wave back, who'd be indifferent, who wouldn't appreciate it: martial artists, marching bands, perhaps even gaps in the parade devoid of people. This would be about four hours of waving.

Four hours is a lot. But I'd already progressed so far. And my only practice had been at parades. What if I trained? What if I practiced? We can teach our bodies to do great things if we practice.

I forget where I was going with this train of thought. Oh, right, physical training. Totally on topic for the book: American Shaolin.

A young man from Topeka dropped out of university to travel to the hinterlands of China and study martial arts at Shaolin Temple. This is his memoir. There is life in China. There is life in the martial arts community. There is a hint of life in a temple community. There are jokes. It starts with an insightful quote from Snow Crash about how young men think they can train to become the world's toughest ass-kicker. So you know that Matt Polly is well-versed in the classics.

This book is a good read. Apparently, this book was a best-seller last year. Probably you already heard of it. If you were going to read it, you probably read it before I did. But just in case, I'll point out: it was a fun read, it was well-written. Check it out.

Yesterday, my office-mate told a story about the struggle with stuff. Her house had a lot of clutter. She was sick of it. So she cleared stuff up. She got stuff organized. She gave stuff away. She discarded stuff. There was that moment of triumph when she realized she could see the floor. A while later, she went up to her son's room. There were boxes in there, boxes full of stuff. Apparently, her task was more Sisyphean than she had realized.

Where had all of these boxes come from? Her ex-husband had heard that she'd cleared some space in her house--so he'd sent over some stuff from his house to store. I immediately thought about my teeny-tiny apartment, which is bursting at the seams with stuff. People look at me funny when I say I don't have room for a TV in my apartment, like I'm saying something philisophical about TV or judgemental about mass media or... whatever. These people have not seen my apartment. People who have seen my apartment just nod in agreement. I have too much stuff for my apartment. So when I heard my office-mate's story, I thought it would be great to have an ex-wife. I could box up all of my useless crap and send it to her. That would be awesome. (Though, on later reflection, I figured out that the process of acquiring an ex-wife is even more painful than dealing with a storage company, so never mind that idea.)

Anyhow, people have a bunch of physical possessions. Physical possessions are a hassle, so probably we can learn something about ourselves by looking at which physical possessions we think are worth hanging onto. That's the basis of Snoop. It's about personality, what your stuff says about your personality, and your stuff doesn't say about your personality but people will draw conclusions so watch yourself. It's not just about physical possessions--it's also about how you carry yourself, how you interact with people.

This book is about figuring out someone's personality by looking at their stuff and outward appearance. What can you figure out about someone by browsing their bookshelf? By watching them walk? By looking at their Facebook page? (And what can you figure out by looking at their homepage (other than that they were narcissicistic enough to set up a home page in the first place)?) What can you find out by rooting through their trash?

You probably already have some good ideas what you can figure out--and some misconceptions. This book is about some psychologists who studied correlations between personalities and stuff.

They like the Big Five (a.k.a. "OCEAN") measure of personality--instead of clustering folks into types, it attempts to measure five aspects of personality. (I'm a O5-C74-E12-A32-N9 Big Five!!, at least according to one on-line personality quiz.)

Don't try to draw too many conclusions from one object; look for the big picture. If you see that someone has some organizational aid, don't assume that they're organized--check to see that they're using it correctly. Sometimes someone will set out one item that they hope will be noticed; that item might reflect their personality or it might not. Sometimes someone will have some item that catches your eye because it seems like a clue to their personality--but it's an outlier; maybe a gift, maybe something they picked up for someone else; maybe something that's just plain unusual for them.

When trying to judge someone's personality based upon their bearing, how they present themselves: You probably can't figure out Open-ness, though people try based on refined appearance, friendly expression, and calm speaking. If you want to know if someone is conscientious, see if they dress formally; don't look for plain dress, nor a controlled sitting posture, nor calm speech. You can figure out if someone's extraverted based on how they carry themselves. To know if someone's agreeable, see if they have a friendly expression, but don't rely on lots of smiling. You probably can't judge someone's neuroticism based on features you might think would work: grumpy expression, stiff gait, unpleasant voice; you can get a hint that they're neurotic if they wear dark clothes.

When trying to judge someone's personality based upon their living space. For open-ness, look for some unusual objects, look for a variety of reading material. To know if they're conscientious, look for organization, neatness, and comfort. (You might not have thought to look for comfort.) Don't try to figure out extraversion or agreeableness. When judging neuroticism, ignore stale air, but do look out for inspirational posters.

To guess someone's open-ness, look at their web presence, their office, the variety of their music tastes. To guess someone's conscientiousness, look at their website vs their Facebook profile--Facebook guides you away from a cluttered look; look at living space or how they carry themselves in a short meeting. For extraversion, check the Facebook profile or (duh) watch to see how they interact with people. For agreeableness--maybe you're not going to get a strong indicator. For neuroticism, look at living space, personal web site, or how they interact socially.

This last weekend, I pitched in for a playtest of MSPH12 "Jeopardy!". These puzzle-solving endeavors have wonderful moments. Solving puzzles in a team environment--it's very satisfying when my skills complement someone else's and we solve a puzzle quickly by playing off each others' strengths.

I tell people about this stuff, and they're interested at first, until I 'fess up that it's not all about shining flashlights at carefully-constructed paper models of the Las Vegas skyline--it's mostly sitting, thinking, and scritching little notes. It ain't rock and roll, though in conversation I probably paint it exciting.

Of course, I'm thinking about a book as I write this. I'm thinking about Crypto, about another activity full of secret messages.

This book is by Steven Levy and thus has a faux rock-n-roll rebel subtitle: "How the Code Rebels Beat the Government--Saving Privacy in the Digital Age." And there's an awful passage that reminds me of some of Levy's worst writing:

Profane, cranky, and totally in tune with the digital hip-hop of Internet rhythm, they were cryptographers with an attitude.

Argh. Even if the Internet had a rhythm and even if "digital hip-hop" described that rhythm, I don't think the cryptographers could be described as... arrgh. Oh, and he kinda gives partial explanations of some crypto techniques, explanations so incomplete that they're less help than nothing. Arggh, aiyee.

But

But

But if you can get past that, this is a pretty well-researched history. Levy talked with plenty of cryptographers and other figures. And he shows both sides--I still think that the Clipper Chip was a bad idea, and maybe I still can't respect Al Gore for backing it--but I can kinda see how he got roped into supporting it; maybe I can see how well-paved his hell-bound road was.

I got an idea of the personalities of Diffie, Rivest, and some other big names. The story of the coining of "cypherpunks" is in here. There are plenty of good anecdotes. All in all, a worthwhile piece of work.

How to get programmers to get along together. Attempts to use psychology to design easier-to-use computer language features. Discussion of which is better for your organization's culture: batch processing of punch cards or time-sharing. Ahem, yes, that's right, I said "punch cards or time-sharing." This book is from 1971. Wow, that's even older than Peopleware. So it's interesting, but in sorta the same way as when you're reading Knuth and you're thinking "Wow, this book is so influential, I'm gonna learn a lot and--wha hey why is he talking about this weird non-Intel architecture OMG did people really argue about what the correct size for a byte is, I mean, c'mon?!?" Apparently, time-sharing was a not-unmixed blessing. If you get a bunch of geeks waiting in line to turn in their punch cards, sometimes they talk about useful stuff.

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.

It's a novel by Andrea Barrett, but it's not about scientists or even lab assistants. Who knew that Barrett wrote about anyone other than scientists and lab assistants? This novel is about people. Oh, the novel is named after a popular science book, but this is weak sauce if you were hoping for another novel about scientists. The novel itself is quite satisfactory, once you get past the fact that it's not about scientists. But I'm not sure what to say about it. This book compares our thoughts/hopes versus reality; it's a relationship like that of parallax, the distortion that occurs when you look from the air into water... oh gee, I can't believe I'm talking about this. This book is literature. If you want metaphors and themes and stuff like that, this book has them in abundance. It's a fun read if you're into spotting those things.

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.

I didn't finish reading this book. It's about software usability. Well, the first few dozen pages were about the importance of software usability, with precious little advice on how to achieve same. I didn't need convincing. I needed advice, but wasn't willing to slog through all those Reminders of Paramount Importance to get to whatever advice there was, if any. So I laid down that book.

Yesterday, I watched a co-worker give a "practice" thesis defense. My workplace has plenty of grad students who are just, uhm, taking a little break from school. He's one of them. I, on the other hand, am the grizzled industry veteran who didn't go to grad school, was pretty darned glad to get out of school and into business where we learned really useful stuff like 286 assembly language. Uhm, whoops. Anyhow, this guy is presenting his thesis, and as part of it he gives a demo of some software. And I growl out "Working code? I thought you said this was a thesis." And I felt bad immediately--here's this guy working so hard towards an advanced degree, does he really need me making fun of the ivory tower right now? Probably not. Anyhow, he talks about what he's been working on, and it's pretty interesting and makes it pretty clear that he's had to done some new, clever stuff. And then he starts talking about how this research might be useful. And someone else in the room pointed out "Hey, it's a thesis--it doesn't have to be useful." And I'm sitting there thinking Hey he said it, not me and who said it? Another co-worker--but he's also a part-time lecturer at a local university's computer science department. Ah, academia. Folks cloistered away in search of knowledge; it can be awkward when they brush up against the real world. Which reminds me: I read Anathem and it was pretty good.

It's scary when you look at it--it has plenty of pages, more than plenty. But it flows quickly, the pages turn. There are ideas inside. You remember ideas, right? They're supposedly why we read science fiction. Far-out ideas, not just another space opera.

On the other hand, it seems cruel to discuss the ideas in Anathem since most of them are introduced as big Reveals. "Isn't it interesting, the idea of Soylent Green being cannibal behavior--reflecting the lessening value of human life..." So reviewers talk about the beginning, which shows us a universe in which a sort of Clock of the Long Now has set up clock/abbeys at places around the world, co-existing with a society somewhere between our own and a sort of tech-instead-of-magic Dying Earth.

I ended up disagreeing with the internal consistency of the book's premise. But I had to think about it. And it was fun to think about. And it's a fun book even if I disagree with the premise. Probably that's because the book isn't just about ideas. There are some fun characters running around in there, too. Towards the end, things seem like an action movie, but it's an action movie in which you care what happens to the characters--and also the action gets weird in places due to... due to ideas which I'm not going to discuss, lest I ruin the Reveal.

Fair warning: this book introduces some strange vocabulary. If you made it through The Book of the New Sun, you won't have trouble with this book. If you do have trouble with this book's vocabulary, be aware that there's a glossary in the back. At least, the edition I read had a glossary at the back. (And even if it hadn't, of course the internet would have come through with the info.)

This book is about cleaning up HTML, the markup language used to write web pages. It's a good book. I'm going to kvetch a lot about parts, but... kvetching comes easy. Anyhow.

You know how liberals are famous for losing credibility with normal folks by... by looking at things from both sides out loud, shooting themselves in the foot along the way? This book is kinda like that at first, but it gets better. It loses credibility early on by arguing at length for XHTML over HTML. There is the usual list of reasons that people use when boosting XHTML, none of which apply to folks writing HTML by hand. Yet, that, apparently, is the audience: "Writing correct XHTML is only even mildly challenging when hand authoring in a text editor." That last sentence indicates an author out of touch with reality as most people experience it. This is forgivable, understandable. The author, Elliotte Rusty Harold, has been looking at raw XML more than most people. He has written more books about XML than... he's written a lot. He has no doubt learned to look <through /> a <forest /> of XML-ish <angle /> <brackets /> (in the same way that an experienced LISP programmer (easily) keeps track of a prairie (of parentheses)). But there are other pieces of advice--assign an id to each element, e.g.-- which suggest that he doesn't normally work in raw XHTML (or HTML); no-one could wade through that much clutter. (In his defense, he does back off and suggest that it's enough to add ids for just some of the major elements--but he says the trade-off is for bandwidth; never mind the sanity of the folks trying to read & edit the code later.) And he misspelled Marc MERLIN's last name. And-- a-- and--

And hang on don't run away; there's a lot of good stuff in this book. This book is basically a big list of ways that you can improve your HTML--and other aspects of your web site. I wish more webmasters would read this book. Though not all pieces of advice apply to all sites, many of them... I wish more webmasters were exposed to more of these issues. I suspect that most webmasters aren't aware of many of them. I wish more webmasters studied up on web accessibility. And I don't really think that the author Harold is an insane XML freak who has lost his instinct for XML's unreadability--I looked at his web page and it's in HTML, not XHTML; Harold doesn't force himself to deal with hand-editing XHTML. To be clear: Harold's web page's HTML is quite readable.

I could imagine using this book as a checklist for sprucing up a site--not following all of the pieces of advice, but considering them. It covers a wide swath of ground: encodings, programming, HTTP, SEO, usability... there's plenty of good stuff here. Check it out; keep your grain of salt handy.

I'm a technical writer. Technical writers write tersely. This promotes quick comprehension. If your writing is translated, there is another benefit. The translator does not need to work so hard.

Holidays are generally good times. Friends who have moved away come back to town. I don't even mind when they call up to say that they're running late for dinner before a show at the Fillmore. (Aside: To gloss my twit, the sousaphone joke was a lame joke I told at the Fillmore. The opening band, Crystal Antlers, was setting up. They seemed to have a lot of equipment. "All they need now is a sousaphone," I said. But partway through their set, out came a sousaphone. Except that now that I do an image search on "sousaphone", I see that I had the name of the instrument wong--though they did haul out the instrument I was thinking of. It might be called a "melodica"? Wow, this is turning out to be a long aside.) I especially don't mind this if I'm next to a bookstore. Bookstores are good places to loiter. I wandered over to the Kinokuniya bookstore. I don't remember much Japanese, but I remember some. I drifted over to the computer section. I could browse titles there--they'd mostly be in English or in phonetically-spelled out English.

Googleを支える技術 had "Google" in the title, so I thought it might be interesting. (This is a good time to re-iterate that my opinions are mine, and might not reflect those of my employer who might find books about Google really really boring for all I know.)

I expected it to be a book about searching, but it was about Google's technology infrastructure. It was pieced together from public information--there were chapters on GFS, BigTable, the things you can find out about. Also, there was a chapter on engineering culture. And therein I spotted the sentence that caused me to buy this book:

GoogleのソフトウェアエンジニアであるSteve Yegge氏は、自身のブログで次のように述べています。

I didn't know enough Japanese to know exactly what that meant, but I could tell it was about Google engineer Steve Yegge. This was good news--maybe I could use this book to give Steve a hard time. So, like I said, I bought the book.

I finally got around to typing that sentence in. It took a while. To type in Japanese characters, you pretty much have to know how to pronounce them. Do you know how to pronounce "氏"? Yeah, like I said, it took a while. (Yes, I tried typing in a couple of words and then searching the web to see if the text was already out there. No dice. No, Amazon's search inside the book doesn't search inside this book. I tried all that, see?)

I was glad it was a short sentence to type in. This promoted quick comprehension. If your writing is translated, there is another benefit. The translator does not need to work so hard.

Oh, right, what does the Japanese sentence say? It says, roughly, "Google engineer Steve Yegge said in his blog." This part of the Japanese book was talking about code reviews. Steve Yegge mentioned that the Google codebase is clean.

Now think about what I said about writing tersely.

Now think about some poor sorry Japanese slobs reading Steve Yegge's blog posts.

Ha ha ha ha.

Uhm, for those of you in the audience who don't read Steve Yegge's blog, his blog posts are long.

Nevertheless, this guy Yasushi Aoki has posted translations of some Yegge posts at aoky.net. I salute you, Yasushi Aoki. I wore myself out just typing that one sentence into an automatic translator. I wondered if "aoky" might have a meaning other than just pieces of the translator's name. I tried searching the web for the "aoky", and the first hit was a Japanese web page which suggested that AOKY is an initialism. I fed that into the auto translator and got:

It first opened for YORO

A-AKEMASHI

O Happy

K a year

Y hi

Stands for.

I don't really understand what that means, but I'll take that as my excuse to say: Hi Happy a year! See you in 2009!

This book is a classic amongst computer programmers. Well, it's a four-year old classic. It captures the, uhm, zeitg^W movement towards unit testing and refactoring. It shares a problem with other classics: you've already heard its message, heard it from other sources.

Legacy code is scary. Within it lurk strange pieces of code. You look at a piece of code, a piece of code that had a purpose once. But that code has been changed over the years; now it has three purposes, each of which it kinda half-does by working with some other pieces of code which you wouldn't expect to be related. One way to deal with this is by surrounding the strange code with unit tests. Now if someone changes some code that alters behavior, you get an early warning. Blah blah blah.

He also lists a bunch of refactorings useful for making code quickly & easily testable. The first few of these in the list--I'd already heard of them. So I kinda zoned out for the rest of this part of the book.

I liked Spin State, a science fiction novel by Chris Moriarty. It's science fiction but with a story in which the characters make mistakes. That's a good thing. I actually found myself thinking literature-ish thoughts, all mixed up in there with the quantum entanglement. It's good to think about quantum entanglement and human frailty at the same time. Plenty of the action takes place in a claustrophobia-inducing mine. Well, I don't think that the characters were getting claustrophobic, but I was. A tense book.

Computers are hard. This afternoon, I was trying to figure out why some people couldn't view my web site. It sounded like a DNS problem; one guy reported it was affecting him on Comcast in Boston. So I tried Googling for DNS problem reports; I found people complaining that Comcast provides crappy DNS. I don't know if that means that Comcast provides crappy DNS or if that means that Comcast has many customers and thus has more people to whine about it. And then I got sidetracked when I found out that I no longer know what organization manages san-francisco.ca.us. Back when I set up this domain, san-francisco.ca.us was managed by an outfit called Tycho.net. They were the (something something) delegate. No one outfit was going to try to handle registering all of the .us domains; depending on what region you wanted a domain in, you'd deal with some local delegate. Thus, tycho.net. Don't look them up, they no longer exist. I found a forum post which reported that tycho.net got gobbled by something which got gobbled by something else which got gobbled by sonic.net. If sonic.net still manages san-francisco.ca.us, I didn't find any evidence of it on their web site. www.nic.us seems to imply that www.nic.us manages it--but it doesn't have any record of my domain. So the good news about my domain is that it's free, but the bad news of "free" is that if no-one's cashing your checks, then maybe you don't know who you're dealing with.

Computers are hard. Anyhow, yeah, book report, yeah, Code Complete, here we go.

This is one of those influential books that I didn't get much out of because their ideas have already percolated out into society. Heck, a large part of what it does is distill down ideas that had already percolated around society long ago. This book takes the time to summarize both sides of the goto-considered-harmful debate. So I kinda spaced out most of the time I was "reading" this book. Still, there are advantages of skimming over a book that's considered an authority of sanity and stuff.

I'm thinking of this section in particular:

Taking pictures of whiteboard drawings with a digital camera and then embedding those pictures into traditional documents can be a low-effort way to get 80 percent of the benefit of saving design drawings by doing 1 percent of the work required if you use a drawing tool.

I do that. I draw on the whiteboard and snap a photo instead of diving into you favorite diagram-drawing tool. And people laugh at me when I do. But now I can point at this book. I can say, "It's in Code Complete, thus it is accepted industry practice QED."

In a passing reference to this book, The Craftsman, I got the impression that it was a book that studied how people think when they're working. But it isn't that at all. I wish instead people had pointed out this sentence from the book's Prologue:

I am a philisophically minded writer asking questions about such matters as woodworking, military drills, or solar panels.

There might be some useful information in this book. But I'll never find it. I gave up on this book. It is larded with philosophy. One imagines that the author, Sennet, felt compelled to write this book because he is surrounded by philosophers who are unfamiliar with doing real work and he felt he had to explain the process to them in their own language...

First and foremost, by putting manual pursuits on an equal footing with mental labors. The general idea had a sharp edge; the Encyclopedia scorned hereditary members of the elite who do no work and so contribute nothing to society. By restoring the manual laborer to something like his archaic Greek honor, the encyclopédistes mounted a challenge equal in force to Kant's attack on traditional privelege but different in character: useful labor rather than free reason challenges the past. The very march of the alphabet aided the Encyclopedia's belief in the ethical equivalence of manual work to supposedly higher pursuits. In French roi (king) lies near rôtisseur (a roaster of meats or fowl), just as in English "knit" follows upon "king." As the historian Robert Danton observes, the Encyclopedia seized on such couplings as more than happy accidents; these take the authority of a monarch down a beg by making it prosaic.

So the real is problem is that I misunderstood what the book was about. This is not a book about how we think when we work. It is a book about professional thinkers thinking about work. What did Kant have to say about work? Diderot? If I cared about these things, then I guess I could read this book to find out. But hopefully one of my friends would cajole me into caring about something important instead and I'd get back to doing real work.

This is a book about DEC, Digital Equipment Corporation, a start up that grew big. The author argues that some of the things that made it a great start-up, a great place to work... these things also were the seeds of DEC's destruction. The company believed in innovation and shipped many products. But it never had a good way to figure out which of these products made money and which were a drain. And there were plenty of drains. Similarly, the company trusted its people to do great work and didn't waste time trying to monitor people. But there were some people who weren't doing great work and some people working on useless things. There was no way to detect these people. The company used the honor system, and it's quicker+easier to get a picture of what the company is doing if you trust the reports of a few managers instead of putting a lot of effort into cross-checking. But once some manager started distorting facts, trust backfired.

While the company did well, these problems weren't serious. The products that did well financed the others. But as microcomputers chased out DEC's minicomputers and the company needed to change, these problems became more important. The lack of clarity about which parts of the company were doing well made it difficult to steer the company towards survival.

This was a discouraging book. It suggests that a company that grows past a certain point runs into some awful problems--problems whose solutions are only mildly better than the problems. I work at a big company. I don't want to spend a lot of time reporting on what I do; just to help fact-check. I don't want to be limited to projects that fit a certain mold so that higher-ups have an easier time keeping track of what the company overall is doing. This book suggests that my attitude might doom my company. I hope it's wrong.

I came up with an idea for a board-game like computer game. The board was going to be a map of the city. And there were these bits of secret info to move across the city. You control some agents that can move info. Or they could recruit ordinary citizens to move the info instead. Folks could pick up info from "drops" and carry them to other "drops". It as interesting to think about how to generate a fake city map, how to choose where to put the drops, how to figure out some "routes" for citizens... But it was shaping up to be a game with as many chores as any Real-Time Strategy game, but without the cool explosions. That's the problem with a quiet spycraft game. Not enough explosions.

Oh, right, my point. Spies. The Ipcress File. It's a spy story. It's a fine spy story. It's nice enough. It was kind of tough to get ahold of--my usual libraries had lost track of their copies. I ended up getting it from Link+. Which seems a little silly since I didn't like the book that much. How did this end up on my reading list?

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.

During BANG 18, I found out that plenty of local goyim puzzlists don't know what a "golem" is. A puzzle required players to recognize monsters by looking at pictures. I thought that was pretty tough--but I didn't think that a golem was the toughest monster to identify. But it was for plenty of folks. Back in my day, nerds were required to play Dungeons & Dragons, and were thus forced to learn the basics of Golemnity. It was right there in the Monster Manual. If you can't bring yourself to play paper and pencil RPGs, you could at least read Kavalier and Clay. If you can't bring yourself to read a re-hash of old comic book publishing industry tales, you could instead read He, She, and It.

This cyberpunk novel features romance, Jewish legendry, and "glop" as an abbreviation for "megalopolis". Fun stuff, check it out. Contains only 80% of typical patriarchy levels for a science fiction novel.

This book came out ten years ago. It discusses how people make decisions. Not necessarily how people ought to make decisions--but how they do. It does have some advice on how people can make better decisions--not by trying to fight our natural decision-making patterns, but by nudging those patterns. It's well-written. I didn't get much out of it-- I'd already heard most of what it had to say. Risk of reading a classic. A fun read, but depending on what else you've read, maybe not the best use of your time.

It's a novel of The Culture. If you didn't like other novels of The Culture, you probably won't like this one. If you like other novels of The Culture, you probably will like this one. If you haven't read any other novels of The Culture, it's worth checking out. This one is kind of on a Lovecraftian plot-line, with loathsome horror buried sleeping under the water... but it's better written than Lovecraft, and there's plenty else going on. Give it a whirl.

Back in 2002, I went to the British Museum where an old illustration maybe showed a punch-card controlled loom from ancient China--long before such were invented in the West. Bookish fellow that I am, I looked for books on the history of Chinese looms. I hit a few dead ends along the way. One particularly massive dead-end was a huge, sprawling multi-volume work on the history of science and technology in China. "Multi-volume" doesn't do this thing justice. There were a lot of books, each of them heavy. It had a volume about silk cultivation in China, with promises of another volume, about silk weaving, to come in the future. But that future volume hadn't materialized, at least not that I could find. And yet this work had plenty of volumes.

I didn't have that set of books in mind when I picked up The Man Who Loved China, a biography of Joseph Needham. But I should have--Needham was the scholar woh organized and kick-started that massive multi-volume work. (Dieter Kuhn wrote the volume about silk-growing, but doesn't show up in this biography.) Chinese people, it turns out, invented a bunch of stuff. Nowadays, we know this. Back in Needham's day, we didn't know this. And by "we", I don't just mean European honkies. Plenty of people in China didn't know this about these discoveries--the local history of science was in scattered notes. Needham listened to a few Chinese scholars claiming that China had invented this or that--and decided to do some research. And encouraged other folks to gather their research. And put together a rather impressive piece of scholarship. Along the way, he ran into political trouble--China was a tricky political entity back then, and Needham was tricked into siding with China in a faked biowarfare attack--yes, really. There are interesting stories about his travels through China, done during the Japanese invasion. Interesting book, check it out.

If you travel through time, are you free? Or are you hemmed in by predestination? (Postdestination? What do you call destiny when time travel is involved?) That's a complicated question, and fortunately Gene Wolfe mostly ignores it, giving us a fun pirate story. Well, maybe "fun" isn't the right word. It's brutal in places. It's... it's a good book. Check it out.

Last week, I hung out with a lot of technical writers. It was fun. They were from around the world, and they came with some interesting points of view. And with some interesting foreign microbes. Or something. I caught a cold. I think I'm better now. Then again, I thought that yesterday for a while, too. Ah, technical writers, spreaders of knowledge and disease. So I read this book Information Development. It doesn't talk so much about the disease angle, but it covers plenty.

This book is a guide to managing technical writers. You can't teach all of that in just 600 pages. This book is a catalog of things to consider. A few paragraphs about each. Some factors to balance. By following the advice in this book, you could run a great shop or a terrible one. One prejudice does shine through plenty: the author really wants your company to have just one writing organization. Well, maybe she has other prejudices, too. I mostly noticed this one because I disagreed with it. But I do agree with her prejudice towards minimalist writing. She's got a good piece of anecdotal evidence on that (and on the difficulty of measuring the effects of good technical writing):

...the team decided to drastically reduce the volume of the documentation [of an existing product]...

Since the goal was to increase the usability of the documentation, the team members waited with "bated breath" for the results. Once the documentation was released, they were somewhat surprised to learn that the number of customer calls had increased significantly, rather than decreasing as they had expected. However, once they investigated the reasons behind the increase, they discovered that the customers were calling to point out errors in the documentation. In fact, the errors had been in the documents for years. Only with the reduced number of words were the customers reading and finding the mistakes. The result of their innovation was impressive. Customers were using the documentation actively, apparently for the first time.

How many people can possibly want to read this book? How many large technical writing organizations are there out there? I would guess not so many, but apparently there are enough to make a worthwhile market for this book. Maybe that's why the book wants to guide us towards forming big teams of writers--drum up demand for the next version.

I am getting ready for a The Game, and am thus hyper-aware of white cargo vans. This is tricky; while team-mate Wesley is in town, he's staying close to Delancey Street. As in Delancey Street Movers. They have a lot of white cargo vans. I was kind of twitchy in that neighborhood. Anyhow, I guess I'll post a book report: Code Reading

When I was in school, I did an internship at a now-defunct software development company called Geoworks. Some folks worry about hiring students--these kids have been "spoon-fed" assignments, can you trust them to take on more amorphous tasks, to figure things out? But that wasn't my biggest problem when I started at Geoworks. It was the code. There was so much of it. I was used to working on little assignments--a few hundred lines of code, built up over a semester. But at Geoworks--I faced the product of dozens of engineers hacking away for years. Just finding my way around the codebase was tough. Figuring out the conventions necessary to make such a codebase manageable...

I wish that Diomedis Spinellis' book Code Reading was available then. He talks about just that--how to get a handle on a big pile of code. He talks about architecture. He talks about low-level code constructs you're likely to encounter. He talks plenty about C programming (common in open-source programs) which might come in handy if you're a student emerging from a Java-heavy program.

There's some good stuff in this book. I learned a little from this book... which sounds like I'm damning it with faint praise. But remember, I've read a lot of code over the years already; this book wasn't really aimed at me. Mostly, I'd like to send this book back through time, send it back to myself 1991. It would have done me a lot of good.

It's a recent railway travelogue by Paul Theroux. It was difficult to read in places, perhaps because it is so recent. His trip was in 2005-2006-ish. He sees stirrings of trouble around Ossetia--so this was unsettling reading as there was fighting going on in Ossetia. He travels through Europe and Asia; not every place is the site of some historical massacre, but there were plenty of massacres. He goes to Sri Lanka--yes, even though the Tamil Tigers were attacking.

But this journey, like others, is mostly about meeting interesting people along the way. Some are helpful, some are awful, some are tragic, at least one is a sourpuss. There are hard-working rickshaw drivers, one of whom made me cry. Cambodians who survived the Khmer Rouge. Arthur C. Clarke in Sri Lanka. Murakami in Tokyo--visiting a French Maid cafe, no less.

This novel is a lot of fun. There is GIS. There is spycraft. There are references to volapuk, to... I guess William Gibson is showing us that he doesn't need to go quite so far into the future in order to show us weird interactions between interesting circles of human activity. Fun stuff, check it out.

(If you posted a guess about the secret message in the jack-o-lanterns photo, then you were right! Especially considering that was an unplaytested "I have no idea if this is possible" puzzle, I am suitably impressed.)

Busy with work, busy with BANG 19. Things should calm down mid-November. Meanwhile, here's a book report I put together ages ago, I guess I can post it now:

Daemon is a techno-thriller. I read it on an airplane, because that's what you do with techno-thrillers. Daemon fulfilled its purpose admirably; at no point during the flight did I lose my mind with boredom.

Deliver the Vote is a history of crooked elections in the U.S. of A. It doesn't try to describe all crooked elections. Just some good stories, just enough to fill up a few hundred pages.

George Washington bought booze for voters. As far as corrupt electioneering goes, this was pretty benign--Washington wasn't having anybody beat up, shot, or what-have-you. He was just handing out alcohol. Our elections nowadays are fairly harmless--the theft is done through miscounting, not through violence. But there's been a constant theme of theft. If anyone tells you that the 2000 election was an anomaly, laugh at them.

Bleeding Kansas.

Rutherfraud Hayes.

In the late 1800s, Southern Democrats weren't happy about black folks, generally Republicans, getting the vote. So the Democrats used violence and ballot-stuffing to wipe out those votes. When you hear about civil rights folks heading South, risking harm at the hands of violent racist Southerners, it's easy to think, "Well, that violence happened because these 'invaders' riled them up." But the violence had been going on the whole time.

A polling place gets moved to a place where some uppity neighborhood's residents can't find it. Mysterious boxes of votes are "found" late on election night. When the women of Texas wanted suffrage, it was once voted down, with most of the votes coming from mysterious precincts whose polls had never opened.

Bush/Gore does get a mention--the overseas absentee ballots that arrived after the election ended, many without postmarks, but which were nonetheless counted.

Maybe we get the government we deserve, but we don't necessarily get the government we mostly ask for.

This morning, I'm munching my breakfast, reading Slashdot's feed and I see a name I recognize. The strange part: the name is that of a politico, not a computer programmer. The Slashdot post is pointing out that the USA election's dirty tricks are heating up, citing a newsblurb about some flyers trying to scare voters away from polls, warning of undercover police waiting to arrest folks. The newsblurb quotes Allen Raymond. I recognized the name because I read How to Rig an Election, the book that he wrote while in jail, serving time for his electioneering crime.

Allen Raymond helped folks to win elections. This is his autobiography... well, his autobiography that he wrote with Ian Spiegelman. Raymond dug up dirt on candidates. He spread lies. He worked for the RNC. He saw Republicans doing dirty deeds. He didn't have much trouble digging up dirt on Democrats, either. You might think you're already plenty cynical about politics, but don't be surprised if this book makes your opinion sink even lower. Towards the end of the book, there's something interesting for the security-heads--Raymond used a phone bank to Denial-of-Service an opponent's phone bank. A clever trick--and the trick that landed him in jail.