The best books to make you a better software developer

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.)

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.

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.

One of my long-time software passions is the study of algorithms, so I have a lot of 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 that Introduction 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.