Scan barcode
rodhilton's review against another edition
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.
jeffpowell's review against another edition
3.0
The book is nicely written for both readers that have lived through developing software and those that have never written code before; entire sections of contextual explanations are inserted throughout the narrative. The narrative feels like it moves rather slowly though--reflecting some of what was going on with Kapor's struggling start-up.
bkoser's review
4.0
“Dreaming in Code” is a glimpse at the world of computer programming, its culture and its history, through the story of the team that built Chandler. Chandler was supposed to be a revolutionary application; instead it cost millions of dollars, took years to build, and was barely used before the company shut down.
Rosenberg tells the story of the team as they build Chandler, explaining terms and relating anecdotes along the way. For someone like me with a degree and five years’ experience in the industry, there’s not much new information, but that didn’t lessen my enjoyment. I’d recommend this book to anyone studying software development, as well as those who are just curious, “What exactly do computer programmers do?”
As Dr. Donald Knuth said, “Software is hard”; by the end of “Dreaming in Code” you’ll have a good grasp on why.
Rosenberg tells the story of the team as they build Chandler, explaining terms and relating anecdotes along the way. For someone like me with a degree and five years’ experience in the industry, there’s not much new information, but that didn’t lessen my enjoyment. I’d recommend this book to anyone studying software development, as well as those who are just curious, “What exactly do computer programmers do?”
As Dr. Donald Knuth said, “Software is hard”; by the end of “Dreaming in Code” you’ll have a good grasp on why.
casktapper's review against another edition
3.0
There were parts of this book I really enjoyed, but ultimately it was padded out by 100+ pages of uninteresting musings on software
ninj's review against another edition
5.0
Great exposition on the Chandler team, regarding a specific project, as well as software in general. Didn't check the final mix, but it was feeling like the project was only about a third of the material.
Great references too, from Kay and Lanier, to the coining of Software Engineering and its first conferences. The issues of scale, the comparisons to other disciplines and art vs science.
Whilst it instantiates many instances of pain as the team slip backwards and sideways on their grand vision - or, hell, on just getting any software further advanced and written - it is often inspiring, aided by the discussions with either those on the team or outside it musing on their passions and thoughts and ideals.
Great references too, from Kay and Lanier, to the coining of Software Engineering and its first conferences. The issues of scale, the comparisons to other disciplines and art vs science.
Whilst it instantiates many instances of pain as the team slip backwards and sideways on their grand vision - or, hell, on just getting any software further advanced and written - it is often inspiring, aided by the discussions with either those on the team or outside it musing on their passions and thoughts and ideals.
krng's review
3.0
Recommended read for any non-programmer to gain insight into the software industry.
chutten's review
4.0
A frustrating read because of how many of the industry's problems described within remain not only unsolved but in many cases unaddressed. But that's what makes it good. Well, that and how accessibly it describes the problems for non-industry readers (I presume).
Unlike many accessible descriptions, Rosenberg's are (with a few small exceptions) exactingly accurate. Rather than simplifying with analogy he manages to somehow rewrite the problems exactly as they are, but in accessible language. This means reading it as an "insider" it reads as a novel transformation of the problem statements rather than a simplification, which makes for rewarding reading.
Unlike many accessible descriptions, Rosenberg's are (with a few small exceptions) exactingly accurate. Rather than simplifying with analogy he manages to somehow rewrite the problems exactly as they are, but in accessible language. This means reading it as an "insider" it reads as a novel transformation of the problem statements rather than a simplification, which makes for rewarding reading.
einarwh's review
2.0
I'm sorry, but I found this book to be terribly boring and not very informative. In a deeply ironic way, the book seems to share the predicament of the failed software project it describes: it keeps on meandering without getting anywhere. I kept hoping for some turning point or climax, but instead it just sort of petered out into nothingness.
dweintrop's review against another edition
3.0
pretty good - a bit annoying as it is written for non-software developers so time was taken explaining things that I didn't need explained, but understandable. Some good anecdotes came out of it though, so it was worth the read for all software developers.