Complications by Atul Gawande

A friend at work first gave me this book years ago -it was a riveting read then, and still is now.

In a measure of how much I like this book, I’ve since bought 9? 10? copies, each time to replace the copy I’ve given to yet another friend; most recently another one last week. Each of those friends has, in turn, also been blown away by this book.

On one level, it is about how people make critical decisions when they only have partial information. As an engineer, I feel most comfortable making decisions when I have all the data to make an informed decision. But how do you make informed decisions when the act of gathering all the data will take too long; situations where there is no test, or the patient will die before all the test results come back? And as a doctor, how do handle it if your guess was right and the patient was treated successfully? Or live with yourself when your educated guess turns out wrong, and your attempts to make things better actually make the situation worse?

This book, like his other book “Better“, is written as a series of short stories – each chapter covering a different topic with a different patient. This made the book easy to pickup, and stopping after a chapter is a great way to mull over some of the issues raised. But I find the book hard to put down, even after all these years, and all these re-reads. Atul has quite a skill, being able to describe all the nuances of a complicated field like medicine, and medical diagnosis, in a way that is readable, understandable, and totally fascinating, to someone who knows very little about medicine.

The stories include his failed attempts at a routine procedure when starting his residency, the startling twist in the story of a child who had trouble breathing, a debate about how doctors train new doctors, and the very humble, personal stories of patients who died when they should have lived, and lived when they should have died.

Buy it.

(ps:the last chapter gives a great description of part of a rare-enough situation that I had to deal with once, a few years ago, and am very happy to have survived.)

Why was September 2009 so busy?

September was our highest load in the entire year so far, ~37% above our previous record high point this year. Its interesting that this seems to be across almost all branches and even exceeds the load during the last few months of the FF3.5 development cycle?!?


This wildly exceeds our expected load. Personally, I’m impressed our systems stayed up and working correctly, even if they sometimes got backlogged. Last month’s data has us trying to figure out answers to two questions:

  • What was so special about September to cause this?
  • What will October look like?

World of Goo (on wii)

My first impressions of World of Goo still hold true. Its a great game. The soundtrack is so good, the company made it available as a separate download.  All just wonderful.

Now, to make it even better, there is:

  • collaborative multiplayer
  • on wii
  • installed in the Mozilla office in MountainView

I’d intentionally stayed with the demos before now, but I finally cracked after playing the collaborative multiplayer version while in Ireland! So, I bought a copy for the office, and downloaded it to the wii. Try it – you’ll like it!

(Aside: please dont used the first profile tagged within the game; that’s being shared by Aki, JHFord and myself.)

Infrastructure load for September 2009


  • The numbers for this month are:
    • 1,774 code changes to our mercurial-based repos, which triggered:
    • 19,525 build/unittest jobs, or ~27 jobs per hour.
    • 9,375 talos jobs, or ~13 talos jobs per hour.
  • This was by far the most load since we started recording these numbers in Dec2008. This is a 37% jump above our previous record, and is the 3rd month in a row with record checkins.
  • We hit 116 checkins on 22nd Sept; new record for number of checkins on a single day. This beats our previous record of 108 checkins on 20th May, in the leadup to FF3.5 release.
  • We are still not tracking down any l10n repacks, nightly builds, release builds or any “idle-timer” builds.


Here’s how the math works out:

The builds/unittest/talos jobs triggered by each individual push are:

  • mozilla-central: 13 jobs per push (L/M/W opt, L/M/W leaktest, L/M/W unittest, linux64 opt, linux-arm, WinCE, WinMo) and 6 talos jobs
  • mozilla-1.9.1: 12 jobs per push (L/M/W opt, L/M/W leaktest, L/M/W unittest, linux64 opt, linux-arm, WinMo) and 5 talos jobs
  • mozilla-1.9.2: 13 jobs per push (L/M/W opt, L/M/W leaktest, L/M/W unittest, linux64 opt, linux-arm, WinCE, WinMo) and 5 talos jobs
  • electrolysis: 12 jobs per push (L/M/W opt, L/M/W leaktest, L/M/W unittest, linux64 opt, linux-arm, WinMo) and no talos.
  • mobile-browser: 5 jobs per push (WinMO m-c, linux-arm m-c, Fennec linux desktop, linux-arm tracemonkey, WinMo electrolysis) and 2 talos jobs.
  • places: 12 jobs per push (L/M/W opt, L/M/W leaktest, L/M/W unittest, linux64 opt, linux-arm) and 6 talos jobs.
  • tracemonkey: 10 jobs per push (L/M/W opt, L/M/W leaktest, L/M/W unittest, linux-arm) and 6 talos jobs.
  • try: 9 jobs per push (L/M/W opt, L/M/W unittest, linux-arm, WinCE, WinMo) and 6 talos jobs.