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.

If you lead a team, you know that providing clear and actionable feedback is one of the trickiest conversations that you have on a regular basis.

The most effective leaders are those who are able to provide both direct feedback and caring support to their employees––and that’s the central idea of Radical Candor. It provides you with a framework for giving feedback, building strong relationships, actively listening, and building trust.

It’s loaded with practical tips and exercises for fostering open communication. 

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.

The Phoenix Project is a storybook about affect fictious company called parts unlimited.

I swear I must have worked at this company at some point in my career, it feels so familiar! It follows a story of an organization that used waterfall in order to make software and all the problems that happened from using this very old software development methodology.

Throughout the story they ‘discover’ how to do DevOps, slowly improving all of their process is until they have a smooth-oiled software creation machine. This includes many stories about security and why the old ways of doing information security just don't work within a DevOps environment.

The characters in this book are both lovable, and relatable. I would never have thought a fictitious story about an IT department could be so fun to read!