Every software developer should read this book. The perspective is interesting because it comes from someone who decided to write down the lessons he learned after working for 10 years. Lots of simple advice that schools don't promote. In fact, most of the advice lends itself well to people who have worked for a few years and now want to learn how to get better at what they do.In general, it gave me a language to speak to senior developers, project managers and managers. The book is broken down in to "tips" and how to handle many different situations. I have a copy at my desk so that I can refer to things (at least the table of contents). Its by no means a bible for software development, its a nice book to have when faced with problems that are common in the industry.
There are a series of books available and another group I would recommend is the Pragamatic Project Automation, version control and unit testing series.
The idea of this post wasn't to sell you on books, it was to expose you to the whole library of pragmatic books out there. Take a look at Amazon for reviews before you purchase since they tend to have more in-depth ideas behind each book.
From a testing perspective, this is where a dovetail occurs. If I understand how developers should think, then I should be able to communicate to them things they may forget to do. In turn, I can help implement and change the organization for the better based on some basic fundamental ideas. This book is a landing platform for me to start this conversation.
So, go find out more. Over the next few posts, my books will become more testing oriented, some more obvious than others (aka: I'll throw a few curve balls, just to see what you think).
