Love Accelerate? Readers share 100 books like Accelerate...

In my consulting gigs, I come across plenty of clueless remarks. Here's a classic one: “We're falling behind schedule, so let's hire more coders.” Or a more recent gem: “We'll be ten times more productive if we generate code with AI.”

When I encounter such nonsense, I don't facepalm or cringe. Instead, I put on my poker face and drop a quote from The Mythical Man-Month.

In an industry where last year’s book is already outdated, Fred Brooks' collection of essays has been a guiding light for nearly half a century. His aphorisms have become legendary. “The bearing of a child takes nine months, no matter how many women are assigned.” “Adding manpower to a late software project makes it later.” “There is no silver bullet.” The list goes on and on.

John Carmack, one of the greatest programmers of our times, used to revisit this book every year or… show more.

This book’s title is absolutely perfect! There’s no agenda here other than identifying things that will make you a more effective and productive programmer.

That leads to a book packed with solid advice, whether it’s about how to write code or how to think about your career. The authors are consultants, so there are plenty of clear and interesting examples drawn from many different problem domains. That’s super fun for someone like me who’s hyper-focused on a single kind of programming.

I love pattern languages. And Team Topologies brings patterns for team types and their interactions. Most importantly, they address fundamental problems of the software industry: how teams organise for fast flow, and how teams cope with cognitive load. The book steams from the author's experience in the DevOps community, and it is widely used across the world. Last but not least, Team Topologies give us a language that support organisation evolution.

My journey in the world of software development has been arduous and challenging.

One of the common struggles we all face is the overwhelming number of solutions available, making it impossible to fully grasp everything at a deep level.

Just when I thought I had mastered an approach and felt competent in it, a new shiny approach would emerge, demanding my immediate attention. It often felt like a never-ending race to keep up with the ever-evolving field.

This constant pursuit of staying relevant as a software engineer can be frustrating, as it feels like we are always lagging behind the rapidly advancing world. I discovered that knowledge of specific technologies, frameworks, or libraries does not easily transfer across different technology stacks. They are too specific and lack universality. It was then that I turned my focus to more general principles of software engineering.

I realized that there are fundamental engineering… show more.

In my quest (you can also call it a professional career), I’m drawn to complexity since we create software for complex problems. There are books on Complexity Science; however, they are very academic. This particular book gives practical advice to cope with complexity. It acknowledges the balance between the emotional and rational sides and why we must bring our full-self to any aspect of our life. The “don’t be emotional, this is work” proves to be a threat to our mental well-being and kills innovation in a company. In the book, the authors explore how to listen to our bodies in the face of complexity in an accessible way.

Technology allowed us to share information instantly; it also enabled the creation of new products. However, there is the reverse of the coin, where technology is used for abuse. Eva's book comes from her experience with survivors of abuse, and she shows how technology can be abused, and what we can use in our design process to create products that take safety into consideration. It is a must-read for anyone involved in the creation of digital products.

Not only does this book provide insight into the planning and development of one of the first visual IDEs, it’s overflowing with hilarious, profound, and pragmatic real-life lessons for how to manage a software team and deliver a complex project.

As a product of its time, the writing isn’t always politically correct. However, many of the lessons and memes are still part of our vernacular today: Don’t flip the bozo bit; If you build it, it will ship; and [Love] the customer.

Some of its lessons should be memes: Beware of [an engineer] in a room, Be an authority, not an authority figure, and Don’t trade a bad date for an equally bad date.

Some sections show their age in our current world of continuous delivery, but few current books have the humor and concise insight of this remarkable work.

Feedback is something I really struggled with as a leader, and sometimes, despite my many years of practice, it still makes me uncomfortable. This book reminds me why leaning into that discomfort and giving feedback is so important: It’s the most caring thing you can do as a leader.

If we want strong teams, we must build cultures of candor where people feel safe and empowered enough to give honest and compassionate feedback.

The DevOps Handbook is literally an instructional guide on how to do DevOps, properly.

It includes security, it includes how to run operations in a smooth and reliable manner, and of course, how to develop amazing software. It gets into all the nitty gritty, with every detail you would need in order to create a good DevOps system development lifecycle within your organization.

This is a technical book with technical examples.

This book was one of the biggest inspirations for me when I wrote my book.

Running a team of technology experts is really hard, so instead of writing a reference manual or an inspirational leadership memoir, Kim tells the story of a group of people who work together to learn the same best practices that have been in use for decades in the manufacturing and project management industries.

This hits close to home since I can recognize myself and many of my colleagues in each of the vivid characters.