Finding bugs and understanding what is really happening within code is a lostart. Only truly good programmers are able to emulate the processor in theirown mind (e.g. read the code and understand how it might work without goingto the trouble of running it). Adam Barr wonders how programmers aresupposed to build better programs if they do not know what is going on incode. The true pursuit of most software programmers is not creatingapplications from scratch; the reality of their day-to-day work is that theyusually have to deal with inherited code. This code, likely written by someoneelse, must be optimized, tweaked, and improved. Therefore, programmers whoare adept at reading, understanding, and improving code are in hot demand.These skills are drawn to the forefront with the help of this new book.This book is language-independent. The author borrows from his extensiveexperience at Microsoft Corporation and as an independent consultant to showhow programming skills can be honed by going through the exercise of findingthe bugs in existing code. By teaching programmers how to troubleshoot, it isthe author's belief that programmers will learn how to think like a programmer,and ultimately produce better software in a more timely fashion.
This book reminded me the puzzles books I used to read during the childhood. It's written in the same manner only for software developers. The book teaches how to find bugs by example in 5 different languages: C, Java, Python, Perl and x86 assembler. Each chapter contains introduction to the programming language enough to find a bug. Bugs are more than just quirks of the given language, they're more high level logical errors. Also, I liked that the book introduces categorization of bugs, which makes easier to communicate with your colleagues.
Overall, this book can serve as a good training to people who do code review as a part of their daily job.
A great book with a simple concept. 5 languages, 10 short programs in each language, and the reader gets to work out his mental muscles finding a bug in each program. If you can't find the bug independently, there are a set of hints leading you through ways to think about the programs.
It seemed a little strange at first to have 5 different languages, but it really was an inspired choice because it forces you to deal with bugs as logic problems and think more about the commonalities in reasons for bugs.
This was really well put together. I hope the author puts out more books like this . I'll be re-visiting this at a later date to see if I solve more of the puzzles.