Stephen Freeman Rotating Header Image

July, 2004:

Grieving at work

I finally got around to reading Norm Kerth’s “Project Retrospectives”: To me the most important insight in the book is his underlying assumption that people and teams need maintenance at least as much as the product they’re building.

Reading his chapter on _Post-mortems_ (projects that really have failed), I was struck by his recognition of the role of grief and the effect it has on people — how it makes them angry, depressed, difficult, and so on. In my experience, almost no organisations recognise this, which is why Kerth’s work is so important.

Even fewer organisations recognise the on-going effects of grief from events in people’s private lives. You might get a day off for a funeral, but it’s not the sort of thing that people broadcast (and get sympathy for) like a new baby. There are other less public sources of grief too, such as failed relationships or thwarted ambition.

As “professionals” we’re supposed to bury our emotions at work, but we risk having them resurface later when we turn into difficult colleagues without quite knowing why. Some people have a full depressive crash, which will trigger proper help, but the borderline cases are harder to spot. Reflecting on my own history and ex-colleagues, I’ve known people become angry and negative, drink too much, or become just too tired to contribute. The results are not pretty, but the situation is retrievable if people understand what is happening, and a rescue will bring you undying loyalty from the person you’ve helped.

Our society used to handle this better — given the mortality rates it had to. There were formal ceremonies and standard periods of mourning, complete with black armbands, to channel the effects of personal loss. Now we need to present ourselves as invulnerable, and that doesn’t work for most people.

Hackers & Painters

I’ve just finished Paul Graham’s “Hackers & Painters”:

It’s a bit of a polemic (and none the worse for that), and some of the opinions on political economy are contentious, but he writes about truths of software development that most of us don’t get a chance to live up to in a hostile world. Perhaps the most striking point he makes is this one:

bq. “So the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn’t get stale. The right thing to compare Lisp to is not 1950s hardware but the Quicksort algorithm, which was discovered in 1960 and is still the fastest general-purpose sort.” P186

Other languages are really convenience notations to make it easier to manipulate hardware, with varying degrees of abstraction.

My other favourite quotation is:

bq. “Remember what a startup is, economically: a way of saying, I want to work faster.” P107

Bill Clementson has extracetd acres of telling quotations “in his blog”:, so I don’t need to, but he did cite one index entry that gives a flavour of the book:

  gorilla 25
  law 45, 102
  reign of, at Apple 228
  salesmen's 76
  technical decisions by 74, 192