- Paperback: 258 pages
- Publisher: O'Reilly Media; 1 edition (February 22, 2010)
- Language: English
- ISBN-10: 0596809484
- ISBN-13: 978-0596809485
- Product Dimensions: 6 x 0.5 x 9 inches
- Shipping Weight: 10.6 ounces (View shipping rates and policies)
- Average Customer Review: 3.7 out of 5 stars See all reviews (43 customer reviews)
- Amazon Best Sellers Rank: #614,464 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
97 Things Every Programmer Should Know: Collective Wisdom from the Experts 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
See the Best Books of the Month
Want to know our Editors' picks for the best books of the month? Browse Best Books of the Month, featuring our favorite new books in more than a dozen categories.
Frequently bought together
Customers who bought this item also bought
About the Author
Kevlin Henney is an independent consultant and trainer. His work focuses on patterns and architecture, programming techniques and languages, and development process and practice. He has been a columnist for various magazines and online publications, including The Register, Better Software, Java Report, CUJ, and C++ Report. Kevlin is co-author of two volumes in the Pattern-Oriented Software Architecture series: A Pattern Language for Distributed Computing and On Patterns and Pattern Languages. He also contributed to 97 Things Every Software Architect Should Know
If you are a seller for this product, would you like to suggest updates through seller support?
Top Customer Reviews
97 Things Every Programmer Should Know is a collection of short, two page essays, each by an experienced programmer. The book is a collection of tips and tricks for writing code that works, that is maintainable both by the author and by others, and that will best fit the situation. While the book doesn't measure up to some of my all time favorites in the genre like The Art of Unix Programming or The Pragmatic Programmer, it wasn't meant to. This is not an in depth guide to underlying philosophies of coding practices and standards, but quick hit and run articles that would be easy to fully grasp and absorb in short five minute bursts, such as during work or study breaks (which is how I read the book).
Some of the topics included in this book will seem obvious such as "Don't Ignore That Error" and "Comment Only What The Code Cannot Say," and some tips are going to serve only as reminders to best practices that are sometimes ignored (to our own peril) like "Check Your Code First Before Looking To Blame Others" and "Make Interfaces Easy To Use Correctly And Difficult To Use Incorrectly," there are some real gems in the book that aren't so obvious like one author's instruction to "Read the Humanities" because they are a great tool to help programmers learn to effectively interact with people and not just software and the advice that says "Don't Just Learn the Language, Understand Its Culture" so that you will write effectively and idiomatically within each language, rather than writing the same thing using different words.
I can't say that this is a must-have book for experienced programmers, but anyone at the novice to intermediate levels would certainly benefit from what the book contains. I've enjoyed reading it.
Speaking of which, where is the code? A book on programming without code is like a day without sunshine! To give one example: The second essay, "Apply Functional Programming Principles" by Edward Garson, assures you that you'll write cleaner, clearer code after working with a functional programming language, but his assurances feel awfully airy without any examples. Maybe this is inevitable in a book that's language-agnostic. Books like Code Complete and Clean Code are hopping with code samples (in C++ and Java, respectively); as a result, they do a far better job of engaging the reader and making abstract concepts stick.
A notable exception is "Code in the Language of the Domain" by Dan North, which uses code to illustrate a concept and uses it well. You might want to read that one, but you don't need to buy the book to do so: All of the essays in this book are Creative Commons-licensed and can be read on the book's official website.
Here is why Joel Spolsky's books are so good: He tells stories. He gives examples. He restrains himself from bombarding the reader with familiar aphorisms. You're imbibing his experiences, not just listening to him ramble. If you haven't already read Joel on Software and More Joel on Software, definitely do so. Also check out the deep interview collection Coders at Work. It's the 98th thing every programmer should know.
I found essays like "How to Implement Doing it Right vs Getting it Done" to be very helpful and wise. That essay included pratical advice that we were able to apply by changing our design for our in house bug tracking software to include a technical debt tracker. "Coding with Reason" included some decent maxims that I hope my programmers implement, and I will be checking for in future code reviews. It is for these excellent essays among others that the book is worth reading.
As a software development manager who also gets involved in the business side of things I was amused at how occasionally at the contradiction that exist between the business world and the software development world. In the essay "The Professional Programmer" that emphasized among other things that programmers should not tolerate bug lists and take responsibility for training themselves (I agree). However, I know that often times programmers have little control over their time and I know that our fallen nature inclines people who self study (if they do it all) often times to study what they like rather than what is useful to the company. In my knowledge of Business management the opposite advice is given, that in order to keep a motivated workforce the employer needs to provide training and/or training opportunities. Essays pushing pair programming made a good argument for it, but excluded what practical ideas can be implemented if such a thing is not possible.
Sometimes I did not always agree with all the essays nor did I think that certain maxims should be elevated to the level of dogmas. Where the book suffered was that some of the essays selected seemed to reiterate points that where already made in other essays.
I would recommend this book and I will even be using it for our in house book club.
Most Recent Customer Reviews
I agree with everything there
Many right thoughts/experience in single book