I read this book very quickly; it’s definitely a fun, easy read, and an interesting novel in its own right. It was breath of fresh air compared to sort of meandering technical prose I’ve found elsewhere.
A note to the non-technical audience: Almost all the characters in this novel are in IT. There are a lot of acronyms and technical terms. Don’t guess; look it up.
My main criticism is that at times, the book is a little bit “everything’s ok now”-y. In other words, there are a lot of episodes in the book that go approximately, “Everything is terrible!” Then IT people work late nights. Then someone discovers some DevOps magic sauce, and then everything is better. But that’s the worst I could say about it. And maybe, that’s a criticism of me; maybe the episodes where DevOps solves problems seem trite because I haven’t experienced this magic first hand, and I am simply incredulous that it could work so well.
One key benefit of reading the book was that I got to see the difference, close hand, between functional and dysfunctional teams, between good practices and bad practices. Maybe, if we’re critiquing the book as pure literature, the lessons of the book are too obvious, the morals of the stories too overt, but if we’re talking about it as a tool for learning, obvious lessons are good lessons, because you learn and remember them. People often mistake obscurity for brilliance; don’t let that mistake keep you from reading this book.
The biggest single takeaway lesson for me in this book was this: work in progress, that is, tasks that are started but not done, kill productivity. Here’s why: They already took some of your time and money, and they haven’t given you anything back yet. That’s bad. I think perhaps the lesson, from a developer, is to work on one thing at a time. Pick a feature, or a bug fix, or whatever, and knock it out of the park. Then do the next one.
Personally, I have sometimes been guilty of only working on what I felt like, or only working on the thing I most recently got an email about. This is bad, because some things remain work in progress forever. More on this soon, but I can foreshadow a future article: if you work on the newest thing, rather than always clearing out your work in progress, some tasks can stay in progress forever.
I definitely recommend the book, especially if you’re in charge of other people, or if you (or your employees) resent or lack established procedures, and view keeping paperwork current as wasted time. It was also sort of motivating; after reading the book, I would go to work ready to charge in, and solve all the problems. If you work, or plan to work, in a technical field, or especially if you supervise technical employees, I really recommend The Pheonix Project.
Till next week, happy learning.