I read the book Dreaming in Code on Joel Spolsky's recommendation (I need to remind myself that he pronounces his name as Spole-skee, where the first syllable rhymes with "pole". I keep saying "Spall-skee"). Not his direct recommendation exactly. He didn't call me and say "Hey, Champ, read this book, it's good for you!".
Of course, he mentioned it on his blog, even as he hadn't read the book himself. He had been interviewed by author, Scott Rosenberg, though Joel has a minor cameo in the book.
I suppose I should briefly summarize the book as, unlike movies, you're not likely to read the book. Basically, it tracks the creation of Chandler, a personal information manager, something like Outlook. Indeed, it was called the "Outlook killer". The company was OSAF which has "open source" somewhere in its name. The founder was Mitch Kapor who made a ton of money with the creation of Lotus 1-2-3, the spreadsheet program from the 1980s.
Mitch was looking for lightning to strike twice. Indeed, his story vaguely reminds me of a Star Trek episode called The Ultimate Computer, which is about Richard Daystrom inventing a computer called the M-5, which will control starships during battles. Dr. Daystrom's back story includes winning some award like the Nobel Prize of the future. He had been a child (or early twenties) genius making breakthroughs in computing, and this was to be his new breakthrough.
There's some subtext. Daystrom is black (I don't want to say African-American as it's not entirely clear that "America" still exists), and his situation may reflect other bright people of color in the US of the day, but even so, his story has some universality, the desire to reclaim genius, to show the first time wasn't a fluke. Why that's important to folks, who knows? You see it often in sports as coaches strive to achieve greatness all the time, and you see it with filmmakers too. But just plain old genius?
Well, Kapor wanted to create Chandler, and gathered together talented individuals to make it happen. He thought it would only take two years to make it happen, but that was like 2002, and it's now 2007, and I've never heard of Chandler until I read the book.
Rosenberg had to be disappointed with this project, because a non-fiction book, to be entertaining, needs to have some structure that we normally associate with fiction. We want a beginning, middle, and end. I'm sure, by 2005, he was thinking, that this book is already 2 years behind schedule (as was Chandler, of course), and he had to release the book.
The book doesn't merely focus on the key players, but tries to explain software development and its history. For example, there's a mention of the halting problem, which is pretty geeky, but standard stuff for a computer science major with a decent background. Rosenberg compares that to dealing with recurring events in a calendar program.
My question is: who is the target audience for the book? As a software engineer, I'm interested in the software development process. From what I could tell, they suffered from too many cooks. Different people had different ideas, and everyone was good enough that they could make some justification for their ideas. There was some woman named Mimi (I think), who did UI design. One common theme of UI design is that many such designers don't know that much about programming. This allows them to "think outside the box", but also means they don't always consider the feasibility of certain ideas.
Most books don't want to delve that deep into the tech-geek process, hoping there will be some readers who like computer geek stuff that might read it. I dunno. It would have helped if Rosenberg could have followed some humdrum project at a so-so company. Whether he could have gotten permission to do that, I don't know.
The point is that great programmers don't always lead to great code, especially when there are varying opinions.
The complaint I have with Dreaming is similar to Aardvark'd, the documentary tracking several interns at Spolsky's Fog Creek Software as they build Copilot.
To be fair, that documentary didn't even try to appeal to software types (although you think they would). They went for the up close and personal approach, trying to chronicle the individuals involved, rather than how they developed code.
I'll be reading Founders at Work, also recommended by Joel and see how that turns out. Since it's a series of interviews, it won't have a story arc. Instead, it will be about common themes or interesting nuggets.
Three opinions on theorems
-
1. Think of theorem statements like an API. Some people feel intimidated by
the prospect of putting a “theorem” into their papers. They feel that their
res...
5 years ago