Picked it up because of Schneier’s awesome columns in Wired and his generally great blog posts. Glad I did, though it wasn’t what I expected.

It turns out to be less of a book with new information and more of one that organizes the things we already know about trust from game theory, anthropology, and neuroscience. It’s well written, and focused on building a framework with which to understand problems of rule making and rule breaking in modern society.

Three connections I hadn’t made before:

• Corporations cannot be punished like individuals, which makes it harder to force them into compliance, and increases their tendency to defect. The harshest punishment any corporation undergoes is fines, converting a decision that should be affected by moral considerations into a simple question of dollars and cents (and turns the fine into just one more cost of doing business).
• One potential downside to increasing diversity in a neighborhood: as the number of different standards of what's fair and what's polite multiplies, your chances of unknowingly offending someone with your "normal" behavior increases; thus trust in general in the neighborhod declines.
• Facebook is becoming an institution, setting norms for social behavior, and yet it is a for-profit company, with conflicting interests between its profit motive and society as a whole.

So much of software engineering is built on trust.

I have to trust that the other engineers on my team will pull me back from the brink if i start to spend too much time chasing down a bug. I have to trust that they’ll catch the flaws in my code during code review, and show me how to do it better. When reviewing their code, at some point I have to trust that they’ve at least tested things locally, and written something that works, even if doesn’t work well.

Beyond my team, I have to trust the marketing and sales folks to bring in new customers so we can grow the company. I’ve got to trust the customer support team to keep our current customers happy, and to report bugs they discover that I need to fix. I have to trust the product guys to know what features the customer wants next, so we don’t waste our time building things nobody needs.

And every time I use test fixture someone else wrote, I’m trusting the engineers that worked here in the past. When I push new code, I’m trusting our CI builds to run the tests properly and catch anything that might have broken. By trusting those tests, I’m trusting everyone that wrote them, too.

Every new line of code I write, every test I create, adds to that chain of trust, and brings me into it. As an engineer, I strive to be worthy of that trust, to build software that is a help, and not a burden, to those that rely on it.