After the Gold Rush
by Steve McConnell. Subtitled “Creating a True Profession of Software Engineering”. It’s a series of essays examining the state of software engineering today, and arguing that the time has come for accreditation of college courses, a code of ethics, and licensing of software engineers. Whether you agree or not, it’s worth reading for a glimpse at one future we might be headed for.

AntiPatterns
by William J. Brown, Raphael C. Malveau, Hays W. “Skip” McCormick III and Thomas J. Mowbray. “Refactoring Software, Architectures, and Projects in Crisis”. A rather shallow book that seems to be capitalizing on the popularity of “patterns” and “refactoring” by rehashing stuff you could find elsewhere in more concise format. An antipattern consists of identifying a problem caused by ignoring a best practice, and then suggesting the best practice as a refactoring.

Code Complete
by Steve McConnell. “A Practical Handbook of Software Construction,” this fat book includes hundreds of examples of good and bad code in a variety of languages and extensive discussion of why some code is better. Find yourself going back to this book regularly, and especially appreciate the frequent pointers to actual hard data. An excellent distillation of a sprawling and confusing field.

Debugging the Development Process
by Steve Maguire. Tales from the trenches of the early years of Microsoft, with some lessons for software team management. Rated as a fairly minor work, certainly nowhere near as good as his Writing Solid Code (see below). Worth reading if you’re just starting to think about the tradeoffs involved in software development.

Dynamics of Software Development
by Jim McCarthy. Jim was a Program Manager for the Visual C++ team at Microsoft, and this slim book summarizes some of the lessons he learned with that sometimes-troubled product. It tends to be a bit on the light side, and the lessons here are mostly available elsewhere.

Extreme Programming
by Kent Beck. More a polemic that programmers can do good work without planning than an actual methodology here, little indication that it won’t scale or won’t work for everyone, and no measurement. If it comes your way, read it for ideas you can use.

An Introduction to Data Structures with Applications
by Jean-Paul Tremblay and Paul G. Sorenson: Excellent, but alas, out of print. But if you’re writing programs and don’t understand things like linked lists, hash tables, stacks and binary trees, you need to read some data structures book.

Mathematical Structures for Computer Science
by Judith L. Gersting. This is another textbook, and again, it’s not important that you read this particular book, but if you’re going to be developing software you need some of this background. Computer science majors are routinely exposed to this stuff, but those who come into the field in other ways aren’t. If you don’t know what a finite-state machine is, for example, you really do need to explore the field a bit.

The Mythical Man-Month
by Frederick P. Brooks, Jr.: This is a classic in the field, now nearly 25 years old. Nevertheless, many of the software management principles learned on IBM mainframes still apply directly to writing PC software. The book’s title essay makes the point that adding more developers usually makes a late project even later. If you need to manage software developers at all, you need to read this book.

Peopleware
by Tom DeMarco and Timothy Lister. This is a book for managers of software developers. So much of this seems obvious these days: good working conditions, letting teams gel, the effect of quality on productivity…so how come so many managers still seem oblivious? A good first book if you are new to managing developers and want to know how to do a better job.

The Pragmatic Programmer
by Andrew Hunt and David Thomas: A short book of advice subtitled “From Journeyman to Master”. It’s aimed more at individual consultants than big organizations, and language-independent (though biased towards command-line tools; you’ll have to read the book to see the argument they make). Some of the advice is obvious, but there is enough of it that you’ll find a few worthwhile gems. Also notable is that their bibliography includes a list of web sites, and the back of the book has a tear-out card with their checklists and tips for handy reference. There’s also some good stuff at their web site.

Rapid Development
by Steve McConnell: A giant book of rapid development that makes the point that there are many tradeoffs between risk and schedule. With case studies and hard data McConnell evaluates a variety of tools and techniques for rapid development and lays out clearly what you can expect from each. If you ever have a project to deliver under schedule pressure you must read this one. A new classic.

Refactoring: Improving the Design of Existing Code
by Martin Fowler (with contributions by Kent Beck, John Brant, William Opdyke, and Don Roberts): Fowler discusses why one would want to refactor, how to test refactored code (his thoughts on classes containing their own tests are also very worth reading), and gives a catalog of refactorings that he has used over the years. All of the examples are in Java, but the book is worth reading even if you’re working in another language so long as you understand the terminology of object-oriented programming.

Software Project Survival Guide
by Steve McConnell: A high-level overview of the development process targeted at managers and technical leads. McConnell comes out of Microsoft and you can sometimes see the influence of their way of doing things on his thinking. A good overview. But if your organization has no discipline in developing software and you need a place to start, this is very accessible.

Writing Solid Code
by Steve Maguire: Despite a subtitle that many people find very funny (“Microsoft’s Techniques for Developing Bug-Free C Programs”), this is a very solid work concentrated on the mechanics of improving your actual coding skills. About half of it is specific to programmers working with the C language, but the other half applies to any language. Even if all you learn from this is how and when to write assertions, and the importance of single-stepping through every single line of code you write, buying this book will be money well spent.