Love him or hate him, several years ago, Jeff Atwood (of Codinghorror.com infamy and the really rather awesome StackOverflow.com) posted on his blog a recommended reading list for developers. He has since become a sort of mini internet programming celebrity. Since imitation is the greatest form of flattery, I present to you my own list of recommended reading.
Code Complete 2nd Edition, by Steve McConnel should be recommended reading on software engineering degrees at Universities the world over. It is a classic book about the software industry. McConnel makes the distinction between average programmers, who are happy to go through the motions of churning out (usually terrible) code and collecting their wages; and above average programmers, who continually seek to improve their base knowledge, actively improving their skills, who write solid, well designed and easily maintainable code. I think this was the book that really changed my mindset about being a programmer, about being proud of the work I do and the programs I write and maintain.
Working Effectively with Legacy Code, by Michael Feathers is another classic book, and another which I believe should be recommended reading on all University software engineering degrees. The reason I would recommended this book to any aspiring developer is that, more than likely they are going to be working with legacy code. I would say that 95% of the code I work with on a daily basis is legacy code, although that figure is slowly improving, thanks in a large part to the skills and knowledge I've gained from this book. Feathers' defines legacy code as that which does not have unit tests. I would also add that most legacy code is often poorly designed, with no comments and is usually incredibly difficult to maintain. The book is split into three parts, the first part being about how you can bring about change in your legacy code base (and legacy developers!); the second part is like an FAQ, which links techniques together in a way to address common problems; the third part is a reference of the different dependency breaking techniques that can be employed to get your legacy code under test and under control.
The Art of Unit Testing, by Roy Osherove, is an excellent book, full of practical advice about unit testing. The book covers everything, from why you want to unit test your code, to how you can unit test code. Even if, as I had, you have written unit tests before, then you can still learn something from this book. Indeed there were several patterns on how to approach particular problems that I'd not even considered before. Also, I had never really gotten my head around using a mock object framework as part of my unit tests, but this book explains and demonstrates in a clear and concise manner, exactly how you can leverage your mock object framework of choice for your benefit. One minor criticism that I have though, is that I feel there is a certain element of bias toward Typemock Isolator - Osherove is a chief architect at Typemock.
Holub on Patterns, by Allen Holub, is another excellent book, about software design. Design patterns offer an excellent way of not re-inventing the wheel, and Holub offers an entertaining and insightful tour of the majority of the Gang of Four patterns, and offers real world scenarios in which you would use them. The book is very opinionated, but this is not a bad thing, indeed it is refreshing to read as Holub is obviously very passionate about the subject. It certainly opened my eyes into the world of design patterns, as I’m one of these who finds concrete, interesting examples an excellent tool for learning, and I’ve always found the Gang of Four book rather dry.
C# In Depth, by Jon Skeet is an excellent book about the C# programming language. If you want to understand something about C#, and I mean really, truly understand why the language does what it does, then I suggest that you read this book. The book is clear and straightforward, with excellent examples. Honestly if most of the people posting C# questions on stackoverflow.com read this book, then I suspect the number of questions would stop increasing at the current rate.