93 Books Like Ship It!

This book greatly influenced my philosophy around style. Norman's ostensible subject is the design of physical objects, like emergency exits, shower faucets, and refrigerators, but most of what he says is directly applicable to software design and API design, too.

For example: Whatever you expose or document about your interface, the user will take that and form a mental model of the implementation—and he'll program against that mental model, not against your documentation. So you'd better make sure that your interface—by exposing certain details and deemphasizing others, appropriate naming, and so on—suggests a mental model that will be useful to the user (even if it is not correct in every particular).

For example, a horizontal rod mounted on a door affords pushing (a bit of jargon that's entered my technical vocabulary), while a vertical rod affords pulling. If you use the design language of a horizontal rod, people will… show more.

This is the oldest book on my list and is the most underrated. It describes, with serious rigour and detail, how to run more effective software projects and teams.

Most of this advice has been ignored by most of the industry for most of the time but it’s a big part of the reason I’ve worked from home for 14 years and am as productive as I am today.

I was lucky enough to read an early draft of this book and it’s simply the best analysis of the open-source software ecosystem around today.

The writing style is friendly and not formal despite the academic-level research that went into this book. It made me think differently about the open-source projects I maintain and how I interact and chose those I use.

This is from an older generation of open source development, pre-GitHub, but much of the advice here is still incredibly relevant and astute today, helping provide advice on the interpersonal as well as technical sides to open source development.

Many of the underlying principles from this book are what form my grounding as an open-source maintainer for the last 15 years.

Suzanne and James Robertson have been writing insightful books on software requirements for many years. This book covers all the important topics, including understanding the real problem, different techniques for exploring solutions, and numerous ways to communicate requirements effectively. I especially like their treatment of quality attribute requirements and defining “fit criteria” to judge whether a solution adequately addresses them.

The book includes a comprehensive requirements specification template to guide writing a rigorous and complete specification on projects for which that is valuable. I also appreciate their use of visual models both to communicate with the reader and to guide the reader in communicating requirements to project stakeholders. I do prefer my book Software Requirements, but this is an excellent choice as well by two authorities in the field.

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.

I’ve had this book on my shelf for years, and I recommend it all the time! In project roles, I don’t have line management responsibility for the people I am working with, so I have to get things done through others, by influencing, negotiation, and engaging others. I keep coming back to this book because it’s packed with useful ideas, tips, tools, and things to do–and it’s another full-color, attractive read! 

It’s also really easy to follow so no matter what the goal, I can find a strategy that I think is going to work to help me keep my project moving. 

I loved this book because it was one of the most exciting things I’ve read in the project management space for some time. It’s not enough for me to complete a task or project–it has to be fit for purpose and completed in the right way, with the right input from others. And how to actually do that is what I learned from this book. 

It’s a method for making sure what my team creates during a project is actually used and is useful, which means I can show the value we add and how we are making a difference through projects. I thought the practical exercises and tools were fantastic, and the author leaves nothing unexplained–it’s such a thorough guide to managing change adoption. 

This is the most complete take on how to bring diversity, inclusion, and belonging into your team. This is a very practical guide that shows you how to implement this process step by step. Not only does she explain how to respond to the negative tropes, but she also lays out detailed approaches to make sure your allies and angels do maximum good. A must-read if you want to avoid the common mistakes that bog down this process.

I loved this book because it’s so practical and grounded in reality–so many project management books tell you how to work in an ideal world, but the real world is messy. When people get involved in processes and decision-making, suddenly the textbook formulae for how to get work done no longer apply. 

I liked Brett’s writing style and found the book very relatable. Plus, it’s full-color and really nicely put together–and I love a book that is beautiful to read and pragmatic in its advice!