While I was traveling earlier this month, I read Dreaming in Code. I sat down to write this post thinking I was going to write a review of the book but 1) I don’t like to write book reviews, and 2) this book has been reviewed to death. I do, however, want to talk about my reactions to this book, and as a preface to that, I will write a four sentence (or so) mini-review.
I liked the book. In fact, I probably liked it more than most people (for reasons I will elaborate on below). Most people don’t like the ending. The book did end strangely, but it reminded me of the ending of a great tragedy rather than a book that wasn’t written well at the end. In other words, the end of the book was a downer because of the story – not because of a fade in the skills of the author.
It’s been a long time since I read a piece of non-fiction that I had a hard time putting down. The writing was quite good, and the story will be interesting to anyone who has ever tried to create software, but neither of those were the bits that grabbed me. What hit me was a weird feeling – a combination of deja vu and flashbacks to my own career. As I read, I wanted to yell into the pages of the book, or go back in time and join the team and help them. My reading experience was like reading a predictable thriller – while drawn into the story, at almost every point I knew what was going to go wrong and so badly wanted to yell at the characters on the pages to “make a change now to save problems later.” Instead, the team continued to make mistakes completely unchecked. I constantly had that sick feeling you get when you screw something important up – like the time I was careless and let an important bug slip through in a beta release, or the time I rushed through a code review and allowed one of my peers to check in code that made the daily build completely un-runnable.
I’ve spent some time since reading the book evaluating what I do. I love testing, and think I’m pretty good at it. I have a pretty good idea what approaches work well in which situations, and have always been able to find and flesh out bugs quicker than most of my peers. These days, however, I prefer to focus on anticipating where problems may occur. Bug prevention techniques are part of this, but it’s about people too. I want to work with an entire organization to help them work more effectively and more efficiently. I want to help developers create higher quality code. I want to enable testers to find important bugs sooner. I want to help managers make reasonable and achievable goals.
But that’s not testing – it’s something else. Maybe it’s quality assurance, maybe it’s consultant, maybe it’s something else…or maybe it is testing. At MS, we have a three tiered engineering system – development, program management, and test. Of the three disciplines, I would think that my skills and interest always fall under the test umbrella, but I’m wondering if that’s what I really want to do. I guess this work fits in test better than anywhere else, but I can’t stop wondering if testing is not really what I do, or want to do. Sometimes I get frustrated with “testers” who just want to test – testers who are happy to wait for the bugs to come to them. I wonder if my frustration / confusion is because when I think about what they do, and what I do, that they are two completely different roles.
Whatever the reasons, I value anything that makes me stop and reevaluate myself, and this book definitely did that. Making software is hard – perhaps too hard – we know this, but it seems that we prefer to plod along thinking we know what we’re doing, when we obviously don’t.
Maybe what I want to do is just make software less hard to make (or make the mistakes harder to make). What’s that job called?