Jenny and I are at the tail end of our fourth book, Beautiful Teams, and it’s really coming out well. We’ve put together a team of authors who’ve got some really fascinating stories about building software. Each of them has written a really compelling story from his or her past career. We’ve got people writing about all sorts of industries, and running into (and, in most cases, overcoming) a lot of different kinds of problems. All together, the collection is starting to paint a picture of what it’s like working in software.

One thing that I thought would be hard about this project was the coaching. These are software people, after all, not creative writing people. We have a few veteran authors on the team, but we also have a lot of people who hadn’t really done a lot of writing. And the authors themselves, in a lot of cases, were just as apprehensive as we were. It seemed like most of the people we worked with knew they had a good story to tell, but were worried about whether or not they could really tell it well enough.

It turned out that we didn’t have anything to worry about. I was very impressed with how well everyone “got it”. We put a lot of effort into selecting people who had a good story to tell, and it only took a small amount of guidance to help the authors tell them. Even people who hadn’t really done a lot of writing before really took the time to flesh out the characters, give us all the conflict, and really draw out the stories to make them fun to read.

Another thing that Jenny and I really wanted to do with Beautiful Teams was to put storytelling ahead of teaching. There are plenty of books that will teach you about building software. And we knew that there would be a lot of good lessons about software in the book. But our goal wasn’t a book that you could pick up and suddenly do your job better. The goal was to put you in the shoes of someone who’d been there before. Or, even better, we wanted to put you in the shoes of someone who was in a really interesting situation. Or a really bad, or even unimaginable, situation. We wanted to show you teams that were great to work on, and teams that, despite being awful, managed to muddle through. Or didn’t.

We’d never done anything like this project before, and we when we started it, we weren’t sure if we’d end up with engaging stories, or if we’d just get people writing about their boring projects from work. We were lucky. It turns out that on most memorable software projects, there’s some interesting drama: a bad boss, a deceitful or weird coworker, a serious and last-minute crisis that needs to be dealt with, a loud and unreasonable client. And it’s those very things which made the projects interesting that make the stories interesting to read.

At the beginning of the project, I was worried that people who wrote good software might not necessarily be good authors. But they really took to telling their stories. A lot of the authors told us that it was actually cathartic to get their stories on paper, and most of them really seemed to enjoy doing the project.

To me, the best part of the project is the fact we’re having royalties from the book donated to PlayPumps International. It’s a great charity that came up with a novel way to provide clean drinking water to rural villages and schools in South Africa. If you haven’t heard of them, I highly recommend watching this Frontline segment about them.

I’ll post again once the project is done with details about the stories. (We’re still getting the last ones in, so it’ll have to be a surprise for now!)