The Box, Marc Levinson.

In chapter 1, Marc Levinson describes a shipping container and containerport, sketches out changes in port sizes resulting from containerization, outlines a few changes to the world economy that resulted, mentions the impacts on labor, and complains that the historical data doesn't exist to back up many of his claims. You could stop reading here and you wouldn't miss much. I wish I had.

The rest of the book is simultaneously very detailed and not especially informative. Although he throws in numbers in piecemeal fashion, the entire book is a collection of anecdotes, some very long, without much connective tissue or broad scope to convince the reader that the anecdotes should be taken as representational. More fatally, the prose is consistently mediocre. I didn't dislike it enough to abandon it, but I never enjoyed reading it. For a mass market book like this, that should be a fatal flaw.

After all, the author had as his subjects industrial technology, the biggest ships in the world, multi-billion dollar companies, the Vietnam war, organized labor, violent strikes and strike-breakers, organized crime, and a foundation of globalization itself, and still wrote a tedious book. Although the minutia of committee meetings to standardize container fittings might seem to be a dull subject: 1) it really isn't, when you think of the paradoxes and complexities that cause one-inch changes in pieces of metal to affect billions of dollars of commerce and lead to such absurdities as giant fleets of rubber duckies circling the world because a container tipped over in heavy seas, and 2) even if it were inherently limited, recently people have managed to write exciting books about salt, dust, longitude, and the number zero.

But when I read the dust-jacket and learned that Levinson had been an editor at the Economist, it made sense that he could pick a great topic, mention many interesting aspects, and still fail to produce a good read.

An apparently equivalent book, Box Boats, is due out soon; I think I'll try and skim that one in a bookstore before I buy it.

In my current project, I work with a lot of users who are very good at what they do (essentially social work on a hotline), but not especially technically inclined. To the extent that they can be trained to file high-quality bug reports that developers can act on directly, the project benefits. I often step in to rewrite the subject (for example, from "another big bug!" to "search in zip code 91101 returns fewer than expected results"), adjust the priority, or otherwise touch things up. But the users are doing a great job, and probably under five percent of bugs require conversations to clarify.

The key principle in a good bug report is that you have to provide all of the information necessary to reproduce the bug. Corollary to that, you have to have a good sense of what is germane and what is extraneous. Usually it doesn't matter that you encountered the bug on a Tuesday, but every now and then that might be the key to fixing the bug.

The third point I want to make is that one very exciting aspect of open-source projects is that the bug database is in full public view. Every piece of software has bugs, but in an open-source system you can often get the bugs that matter to you fixed sooner if you file good bug reports, make it easy to diagnose and fix the bug, and generally are nice and helpful to the developers. I've had paid Intel developers put in hours fixing a bug in the linux driver for my wireless card; I'm not a big corporate customer, but I was willing to jump through a few hoops for them as they diagnosed the problem. Sure, Intel gets my services as a tester for free, but I get personal bugfixing service that would cost hundreds of dollars otherwise.

With all that as context, check out this bug report from Firefox, an excellent example of how to use "Steps to Reproduce":

1. Create 2 unique user accounts (for steps sake, let's call 
   the two accounts Joe and Mary) in Windows XP Home.
2. Logout and sign-in under Joe.
3. Open Firefox and go to an e-mail site or to jdate.com or wherever.
4. Attempt to log-in to the site so that Firefox will ask 
   whether or not you want your password saved.
5. Choose not to save the password.
6. After successfully logging in and having selected the
   "never save password" option, logout.
7. Log-in as Mary and open Firefox.
8. Browse, browse, browse... but you don't really have to. 
   Just go to "View Saved Passwords," click on the tab that 
   will show you sites to never save passwords for, and you'll 
   see whatever painful site Joe denied to save a password for.
9. Break-up with fiancé.