The Phoenix Project
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is the third book by Gene Kim. The business novel tells the story of an IT manager who has ninety days to rescue an over-budget and late IT initiative, code-named The Phoenix Project.
Stats for nerds
166recommend
340mentions
270people
2013–2026years
57% recommend36% neutral6% critical
Mentions per year
What Hacker News says
- I'm taking a bit of a risk with this one, this is a novella I authored with the help of AI. If that offends you, please move on!
Everyone on HN knows just how much AI is disrupting our industry. Although, much of the industry narrative focusses on the tools, the AI, the harnesses, and their ever-growing capabilities. We need to spend just as much, if not more time discussing the impact this is having on us. Humans will still be a significant part of the software engineering ‘system’, and many of us are rapidly trying to determine what our role will ultimately be.
Storytelling is a great medium for communicating and understanding change. That’s why I really enjoy books like The Phoenix Project — a vehicle for helping people understand the DevOps transformation from a human perspective.
This story is very much inspired by The Phoenix Project: a near-future account of the impact AI has on an organisation deep in the pursuit of speed, ignoring the risks and the human impact.
This story was written with the help of AI. While I can write a decent technical blog post, there is no hope for me when it comes to works of fiction! I have not tried to disguise the AI writing, and I have not suppressed the em dashes — although I did remove one use of the term “load-bearing”! If you consider an AI-authored tale to be worthless slop, I totally understand. I was simply using AI as a tool to help me tell a story that I think needs telling.
- The Goal was written 40 years ago and talks about, among other things, the paradox/illusion of local optima. This isn't new, AI coding assistants are at some level just another NCX-10. This isn't a book recommendation thread, but I highly recommend that book to anyone, even if you've read its IT equivalent, The Phoenix Project.
- Cal Newport, So Good They Can't Ignore You. This book convinced me to stop widening my skillset by beginning again, and start doubling down on my strengths.
Gene Kim et al., The Phoenix Project. This book reinvigorated my love for management, which I lost in 2021–2022. I'm still an IC, but I decided to stop refusing management roles.
Kent Beck, Extreme Programming Explained, 2nd Edition. This book lit a fire under my ass to figure out better ways of working. I followed it up with the next one in a book club at work.
James Shore et al., The Art of Agile Software Development, 2nd Edition. This book gave me hope that a productive, humanist, productivity-oriented workflow can work in today's software world. I read it with my teammates in a book club at work, including the software engineers, QA tester, product owners, and UX designer. Unfortunately the rest of my team had little interest in putting it into place where I work.
Robert C. Martin,
Clean Architecture. This book was a delightful read. Uncle Bob weaved practical advice together with stories from his past that served both to illustrate his points and to entertain. While I don't agree with every word in the book (e.g. Screaming Architecture), I still recommend it to every Senior+ Software Engineer.Eric Evans,
Domain-Driven Design: Tackling Complexity in the Heart of Software. Aside from its amazing content, this book has some of the best typesetting I've ever seen. I sought out a font that is a match (or near-match) and reverse-engineered the letter spacing, line height, heading font sizes, etc. Its content was great too, but I was glad to have read Vaughn Vernon's DDDD first.Vaughn Vernon,
Domain-Driven Design Distilled. This book followed up Shore's work in our book club at work. Everybody on the team really liked what they read, but nobody felt like they had actionable insights. So the engineers went on to read Vernon's IDDD, and the non-engineers read Adzic's IM and Patton's USM.Vaughn Vernon,
Implementing Domain-Driven Design. I read this book with a book club at work. While Evans's work was well-grounded in theory and left a lot of interpretation in the patterns behind DDD, Vernon is a practical, nuts-and-bolts DIY guide to one approach to DDD. Luckily, these tactics resonated with my team and our codebase has seen marked improvements in the past few months. I'm looking forward to our process catching up so we can do more than "DDD Lite."Jeff Patton,
User Story Mapping. This book was fun, practical, and completely outside any way I'd ever worked. It also helped me understand exactly why I've failed every time I tried to make my own SaaS startup on nights and weekends.Gojko Adzic,
Impact Mapping. This book was basically a pamphlet. The process seems...good? But since I'm no longer in a role with the influence or authority to recommend product direction, I doubt I'll get much use out of this for a while.Tanya Reilly,
The Staff Engineer's Path. This book wants to follow in the footsteps of Camille Fournier's The Manager's Path, but it seemed less specific and useful as a roadmap. Perhaps that's because of how different "Staff Engineer" is from company to company, at least when compared to the roles covered by Fournier. But it did help me earn my promotion to* Staff Engineer, so it was clearly worth reading.Tamar Rosier, Your Brain's Not Broken. This book was the second I read after I got diagnosed with adult ADHD. I appreciated that it helped me de-stigmatize, because I harbored some bummer feelings when I realized no actually I didn't grow out of it. It also helped me reflect on my habits of action, and see them in a new light. I was surprised to see how much of my anger and frustration in life was a coping mechanism to help me get things done. I've had a much calmer life since recognizing that.
Alexander Tarlinder, Developer Testing. I'm not quite finished with this book, but I'll be done by the end of the year. It's been a great overview of automated testing from the perspective of a programmer. It helped refresh my memory on things I knew but forgot. It filled gaps that I had in my baseline knowledge. It corrected things I "knew" but was slightly incorrect about. I now recommend this to any programmer, whether or not they've got a habit of testing.
Austin Kleon's trilogy: Steal Like An Artist, Show Your Work, Keep Going. These books were cute, full of incredibly quotable passages, and fun to read. I didn't spend enough time on them, though. A lot of the lessons I thought I'd learned left my brain like water through a sieve.
Kent Beck, Tidy First?. This book helped me understand the economics of software through a new light. That was important to me, because during the time I spent as a Director of Software Engineering I was not given a budget and asked to manage the department's expenses.
Antonio Cangiano, Technical Blogging, 2nd Edition. This book convinced me to start a blog. It was going really well, and then I shrank back from it due to fear of vulnerability. Since I got over those fears and started blogging again, it's been a lot of fun again. I incorporated what would've been tweets into the blog (as "quick posts") in addition to my longer-form, less-ephemeral content (as "articles"). Writing has been a great way to solidify what I've learned and distill my opinions. Heck, I should migrate this comment to my blog.
I also read other books (especially on my journey to becoming a magician), but these were the ones I thought Hacker News might be most interested in.
- Hey everyone!
I recently wrote a short humor novel about life as a dev. It’s called “JavaScript & Drugs: a Dev’s Quest for Ramen Profitability.”
It follows Cramer, a frontend engineer at an HR SaaS company, and his flatmates (also devs) as they go through soul-sucking corporate jobs, startup chaos, and questionable side projects.
You can read a free sample here: https://www.javascriptanddrugs.com/sample
I’m curious: do you think devs would find this kind of story entertaining? I wrote it in part as self-therapy, to let my work-related frustrations out, but also self-published it to see if I can sell some copies. So far, I've only sold 3, all of them to friends and family haha.
Also, do you know any good software-engineering humor books? I’ve read and enjoyed The Phoenix Project and its sequel (The Unicorn Projec)t, but don't know of any other fiction books about dev life.
Thank you all!
PS: yes, I used AI to help me write it, that's why there are so many en dashes haha
- I forgot to follow up here, so apologies for the delay. Honestly, concise is a challenge here. Here is a lot of words, and they barely scratch the surface, but just in case they might be helpful:
- Embracing the idea of a manual valuable process is a great one - as engineers we often want to start by automating and/or building, and dive right in - only to realize later we either didn't understand the product, or our stakeholder didn't and now wants changes once they've seen what it does. (Deeper dives here: "Escaping the Build Trap"[1], "The Minimalist Entrepreneur"[2]
- Understanding negotiation is extremely helpful as you are often operating under constraints, and need to get those across to your stakeholders such that you can both move forward together. Negotiation is basically about aligning two stakeholders with different goals and arriving at an arrangement they can both live with. (Highly recommend "Negotiate without Fear"[3])
- Another excellent concept surrounds the theory of constraints and getting good at recognizing bottlenecks, and subordinating all other processes to them. Essentially, if work is piling up somewhere, look at where it is coming from, and attempt to re-route those efforts to something productive (the bottleneck moves the same speed regardless of how much work is piled up in front of it). The classic book on this matter is "The Goal"[4] but a fun retelling more oriented around an IT department is "The Phoenix Project"[5].
[1] https://www.amazon.com/Escaping-Build-Trap-Effective-Managem... [2] https://www.amazon.com/Minimalist-Entrepreneur-Great-Founder... [3] https://www.amazon.com/Negotiate-without-Fear-Strategies-Max... [4] https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0... [5] https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
- I enjoy “business fables” like The Goal or The Phoenix Project. Since you must know a fair chunk of the business books - any other good ones in this genre?
