Scan barcode
A review by rodhilton
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg
3.0
Dreaming in Code is a book about software development. As a software developer, I cannot tell you how many times I completely related to the proceedings. All of the mistakes, all of the problems, all of the concerns, all of the date slipping, everything. It all felt so familiar, so "been there, man". To some extent, that's the problem with the book.
I've tried to read Dreaming in Code on 3 separate occasions. The idea sounded interesting, and the title alone piqued my interest, so I purchased the hardcover book when it came out. I tried reading it, but simply was unable to get into it. A few years later, I acquired the ebook, so I could read it any time like on the bus or on my phone. I got a bit further, but still lost interest. Finally, I made it through the book by buying the audiobook version of it and listening while driving or working out. It somewhat perplexed me that I had such a hard time getting into the book, considering that I found "Masters of Doom", a very similar book about the struggles of a series of software projects (Wolfenstein, Doom, Quake, etc) to be one of the best books I read in the last year.
The difference between these two books lies in how they were written. Masters of Doom was written after the fact, by interviewing people associated with the projects and assembling an historical narrative from these accounts. Dreaming in Code was written by an embedded journalist, who was actually IN the offices where the software was being written, writing about it as it was being developed and eventually picking an arbitrary point in time to cut the book and release it. The difference is important, for one simple reason. Masters of Doom was allowed to be about some of the most groundbreaking games ever created, with the full knowledge of history at the disposal of the author. Dreaming in Code is about the development of a personal information manager called Chandler, which I never heard of before reading the book.
Masters of Doom was fun not only because I could relate to so many of the trials and tribulations of software development that it discussed, but also because I was familiar with the software itself and interested in its history. Chandler is just some Outlook-esque type program, some boring office software meant to emulate Lotus Agenda (which I had also never used). As such, there is nothing interesting about the software itself or its history, so all that's left in Dreaming in Code is the process of development software, and the issues that arise.
As a longtime software developer, these issues were so familiar to me that I found it almost boring. I was so familiar with these woes that it didn't feel like I was really learning anything or gaining new insight. There were occasional passages that I found enlightening, and I wound up definitely taking a handful of "look this up later" type notes, but they were few and far between in light of the book's considerable length. The book almost would be better suited for someone who was NOT familiar with the process of software development, but as countless conversations about my workday with my wife have indicated, nonprogrammers tend not to give a flying rat's fuck about the process of software development.
I would recommend this book, but not to developers, nor to people with no connection to development. I'd recommend it to anyone who works at a company that develops software, but who is not actually on the development team. Salespeople, customer support, maybe even high-level managers, those sorts of folks. I think the book sheds a lot of light on what goes wrong with development projects, and people whose lives are affected by development projects may well find it very interesting and clarifying. It might also be good for those who are interested in becoming software developers, or college students majoring in Software Engineering or Computer Science (but be warned, the Chandler project is particularly dysfunctional, and I recognized its problems mostly from the worst jobs I've ever had, not the best). Those who live this life will find it boring, as will anyone whose interactions with software are limited to its usage.
I've tried to read Dreaming in Code on 3 separate occasions. The idea sounded interesting, and the title alone piqued my interest, so I purchased the hardcover book when it came out. I tried reading it, but simply was unable to get into it. A few years later, I acquired the ebook, so I could read it any time like on the bus or on my phone. I got a bit further, but still lost interest. Finally, I made it through the book by buying the audiobook version of it and listening while driving or working out. It somewhat perplexed me that I had such a hard time getting into the book, considering that I found "Masters of Doom", a very similar book about the struggles of a series of software projects (Wolfenstein, Doom, Quake, etc) to be one of the best books I read in the last year.
The difference between these two books lies in how they were written. Masters of Doom was written after the fact, by interviewing people associated with the projects and assembling an historical narrative from these accounts. Dreaming in Code was written by an embedded journalist, who was actually IN the offices where the software was being written, writing about it as it was being developed and eventually picking an arbitrary point in time to cut the book and release it. The difference is important, for one simple reason. Masters of Doom was allowed to be about some of the most groundbreaking games ever created, with the full knowledge of history at the disposal of the author. Dreaming in Code is about the development of a personal information manager called Chandler, which I never heard of before reading the book.
Masters of Doom was fun not only because I could relate to so many of the trials and tribulations of software development that it discussed, but also because I was familiar with the software itself and interested in its history. Chandler is just some Outlook-esque type program, some boring office software meant to emulate Lotus Agenda (which I had also never used). As such, there is nothing interesting about the software itself or its history, so all that's left in Dreaming in Code is the process of development software, and the issues that arise.
As a longtime software developer, these issues were so familiar to me that I found it almost boring. I was so familiar with these woes that it didn't feel like I was really learning anything or gaining new insight. There were occasional passages that I found enlightening, and I wound up definitely taking a handful of "look this up later" type notes, but they were few and far between in light of the book's considerable length. The book almost would be better suited for someone who was NOT familiar with the process of software development, but as countless conversations about my workday with my wife have indicated, nonprogrammers tend not to give a flying rat's fuck about the process of software development.
I would recommend this book, but not to developers, nor to people with no connection to development. I'd recommend it to anyone who works at a company that develops software, but who is not actually on the development team. Salespeople, customer support, maybe even high-level managers, those sorts of folks. I think the book sheds a lot of light on what goes wrong with development projects, and people whose lives are affected by development projects may well find it very interesting and clarifying. It might also be good for those who are interested in becoming software developers, or college students majoring in Software Engineering or Computer Science (but be warned, the Chandler project is particularly dysfunctional, and I recognized its problems mostly from the worst jobs I've ever had, not the best). Those who live this life will find it boring, as will anyone whose interactions with software are limited to its usage.