During my career, I’ve worked on projects large and small (1 - 60+ people) in a wide variety of fields (like repair dispatch, ticket sales, and professional football coaching--the NFL kind not the FIFA kind). All of them, and particularly the big ones, were like antique clocks: they had lots of moving pieces and if any piece broke, the whole thing wouldn’t work. (Unfortunately, failed software projects don’t look nice on your mantelpiece.) In this list, I’ve tried to pick some books that you might not discover if you look only for programming books. Read those, too, but don’t ignore the more human-oriented dimensions of software development. Hopefully you’ll find these choices interesting and useful.
Much has changed since this book was published in 1975.
We’ve gone from phones chained to walls to smartphones you can lose behind the sofa cushions. The word “apple” went from being something you eat to something you talk into and stream movies on.
We went from ARPANET connecting a few university computers to the thoughtful, incisive forum of civil public discourse that is the internet today. (Obviously I’m kidding.)
In all of those years, however, some things haven’t changed. Management is still management, people on a development team still need to communicate, and as Brooks's Law states, “Adding manpower to a late software project makes it later.”
This book reminds us that some concepts are eternal and ideas such as the second system effect and the throwaway version are still true. (It’s also a quick and easy read that will give you something to discuss at developer cocktail parties.)
Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.
Software engineering involves several phases such as requirements gathering, design, programming, testing, and deployment.
This book explains techniques that allow you to build quality and robustness into every phase of the process. It discusses design, classes, defensive programming, collaboration, refactoring, and more.
The book uses many examples in an assortment of languages but the concepts apply to any programming language. In fact, the main themes like building error detection into every step of the process generalize to even non-programming parts of the development process.
If you’re an experienced developer, you may have discovered some of this book’s ideas elsewhere or even on your own, but you only need to pick up one or two new tidbits to make the book worthwhile.
Widely considered one of the best practical guides to programming, Steve McConnell's original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices-and hundreds of new code samples-illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking-and help you build…
This is not a software book but rather a book about designing objects to make them more useful, functional, and effective.
One key to that is the concept of affordance, the idea that an environment (such as a software application, hint, hint) can provide features that support the user. Features that encourage correct actions while discouraging incorrect actions.
For example, a door with a vertical handle means “pull” while a door with a flat plate means “push.” (Search online for “Far Side Midvale School for the Gifted.”)
These concepts also apply to software. A dropdown lets the user pick a choice without mistyping, entering “yes” in a size field, or typing “ten” in a numeric field.
This book doesn’t give programming recommendations, but it will help you put yourself in the user’s shoes. I think you’ll find it interesting and informative, and your users will be glad you read it.
First, businesses discovered quality as a key competitive edge; next came service. Now, Donald A. Norman, former Director of the Institute for Cognitive Science at the University of California, reveals how smart design is the new competitive frontier. The Design of Everyday Things is a powerful primer on how--and why--some products satisfy customers while others only frustrate them.
One of my long-time software passions is the study of algorithms, so I have a lotof algorithms books on my shelves.
I have books about general algorithms, graphics, image processing, distributed systems, artificial intelligence, robotics, chaos theory, NP-hard problems (because I like a challenge), and fractals (because they’re pretty).
I honestly can’t pick one and say, “This is the one you should read,” because they all have something to offer, but I will say thatIntroduction to Algorithms is a good place to start.
It explains Big-O notation (which is essential to really understanding algorithms) and covers a nice assortment of algorithms in enough depth for you to understand how they work.
It’s a pricey book, but at more than 1,300 pages (lift with your legs not your back) it covers enough material to keep you busy for quite a while (and is a good pages-per-dollar value).
When people think about software engineering they mostly think about programming, but that’s not where a project starts. It starts with requirements.
(Really it sometimes starts with company politics, bickering, excuses, and backstabbing, but requirements gathering is often the official start.)
A good set of requirements keeps developers pulling in the same direction; a bad one can make the team inefficient, cause endless arguments, set developers against each other, and make the project feel like Lord of the Flies. I’ve seen projects scrapped and restarted from scratch or even canceled due to poor documentation.
Every software developer should know at least a little about writing so they can produce clear requirements and documentation.
This book isn’t specifically about writing documentation (which is something of an art in itself), but it can help you learn how to make your business writing more effective. This book won’t turn you into Shakespeare, Hemmingway, or Pratchett, but it’s a good place to start.
Designed for advanced professional, technical or business writing courses, this concise text covers basic principles, correspondence and reports, and provides a guide to common problems.
A clear, intuitive introduction to software engineering fundamentals that cuts out the jargon and technobabble to explain concepts in straightforward English. It doesn’t assume previous development experience, only that you want to learn how the development process works (or not) and how you can improve the process. It explains development phases and different ways those phases can be organized in methodologies such as Kanban, Scrum, Agile, Extreme, and other approaches that sound like they were invented (or at least sponsored) by energy drink companies.
The second edition includes new material on the cloud, algorithms, UI and UX design (which are sorely neglected by many companies that should know better), programming languages, software ethics (you’ll be surprised at how low some companies set them), and more.
