Customer Reviews

97 Things Every Programmer Should Know: Collective Wisdom from the Experts

5 star:		(5)
4 star:		(13)
3 star:		(3)
2 star:		(2)
1 star:		(0)

 

 

I have read programming books for years. There was a time when I could write a "Hello World" program in each of seven or eight languages. That time has passed, mainly because I haven't been intimately involved in any specific software project for many years. Still, I have this habit of reading programming books and enjoying them, perhaps in the hope or expectation that one of these days I'll find myself with a project in front of me, time to work on it, and motivation to learn a new language or tool to make the project's vision a reality. Well, here's the newest book of programming foundational tips that I have read.

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.

If you're just entering the programming world, this collection of 2-page essays might be a useful resource. But if you've been reading programmer blogs for a while, or you've worked on a couple of projects, then there's little of value here. Very few of the essayists choose to tell stories; instead, they say things like "Remember that humans always make mistakes," "Read other people's code" and "Always leave the campground cleaner than you found 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.

This book is a compilation of short essays ranging on topics as diverse as Bugs, Error Handling, Customers, Refactoring, and Expertise. The purpose of the short essay is not to answer all your questions or be a definitive guide to programming. Rather the purpose is to provide a starting point for a conversation. To this end, I think a practical way to use this book whether in academia or a development team would be to assign groups of essays to be read ahead of time to stimulate classroom or team meeting discussions. Read my full review of the book here,
[...].

As other reviewers have noted there is stuff here that is rather pedantic for anyone who has been programming professionally for more than five years, however there is still a great deal of good material and some interesting discussions. There is in indeed code where it is necessary, you can find some by simply using the "look inside" feature. Programming is about ideas and concepts far more than it is about code and this book has many very lively discussions; the chapter on Floating Point inaccuracies is worth the price of the book.
This book also has the benefit of the fact that we do not work in a vacuum. We learn from each other and when mentoring younger programmers a book like this helps to remind us of the things that were so ingrained in us ten years ago that we might never even think to mention it to our charges.

I read this book because, well, I wanted to see if I knew 97 things that 73 other programmers thought I should know. Luckily, after over 20 years of software development experience, there were no surprises on my part. However, for those just starting out in programming, this would be a valuable read, just to gain a cursory glance at the topics you should become familiar with. For experienced programmers, check it out if you want to satisfy your curiosity. Hopefully, you won't be surprised.

I think a better title for "97 Things Every Programmer Should Know" would have been "General Advice on Mitigating Inevitable Failure in The Field of Software Engineering".

As the title suggests the book consists of 97 short to medium sized essays about programming and software engineering in general. Most of the essays are about practices experienced programmers know in their bones so the book is probably more useful for junior programmers who don't have too many projects under their belt. Many of the essays are pretty general and address things like code commenting, exception handling, encapsulation, minimization of mutability, software deployment, testing, API design, version control, etc. The short format of the essays makes for a quick and easy read and the essays are not bogged down with too many technical details. I only found one essay that was a bit more specific than the others and it was about floating point gotchas and was definitely a good read. I especially enjoyed the example about exp(-x) diverging to infinity for large values of x if the implementation naively uses the power series to compute the answer. For those a little rusty on their math exp(-x) should be practically 0 for large values of x.

Overall there was nothing earthshaking but just general good advice on common sense practices.

I seem to be on a kick lately where I'm reading books that have nuggets of programming wisdom that force you to contemplate what you do and how you do it. This month's book is no different... "97 Things Every Programmer Should Know: Collective Wisdom from the Experts". Presented by a number of technical gurus and visionaries, these 97 two-page thoughts will probably cause you to feel a mixture of emotions, from assurance that you are doing some things correctly, through guilt over taking shortcuts to come, and finally to some frustration over disagreements. In any case, you *will* walk away with a number of ideas to change what you're doing.

There is no pattern or flow to the material as you read through the 97 chapters. In fact, the main order is by alphabetizing the titles of each chapter. But the editor does provide a secondary table of contents to group the contributions by category, so you can choose to read the material in logical groupings if you so desire. It's also important to keep in mind that this is really a "crowdsourced" compilation of what programmers should know. Given that there is no "one true way" to do things, you may find that some of the ideas and contributors don't necessarily agree with each other on all points. But that's OK, as you should read the material and think about what's being said, knowing that your angle or approach may be slightly different (and potentially just as valid) than what you just read.

Even in the short time I've had since finishing the book, I've already started to refer back to some of the information. For instance, "Ask 'What Would the User Do?' (You Are Not the User)" was driven home the other day when I was debugging an application issue that seemingly could not be reproduced. As the developer, I followed the steps exactly as designed, and always got the correct answer. The problem is, the users *didn't* follow the designed path, and I was blind to a very valid and understandable path they would take. I need to remember... I am not the user.

Another one that haunted me just last week (fortunately, I was not the offender) was "A Message to the Future." The contributor makes the case that every line of our code should be a message to the future, to the smart person who will inevitably have to solve a problem with this code. Make them want to say "This is great code, and it's an elegant solution. I can understand it immediately!" If you can code in such a way to make the world better for Phil (the smart person you haven't met yet), then the world truly will be a better place. I only wish the person who had left me a really nasty bug in one of their agents had been practicing that idea...

Some of these ideas might not be where you currently live in the tech world, but you will find a number of contributions that *do* hit you right where you live and breathe each day. And since just one great idea can change your whole perspective, "97 Things" is a very good investment in yourself, your career, and your future.

This is another great book in O'Reilly's "97 Things Every <fill in the blank> Should Know" series, and it's every bit as good as the others. The book follows the same highly successful format of creating a book full of two-page articles taken from submissions to a public wiki. Each article is concise, highly pertinent to our profession, and well-written.

The articles are grouped in broad categories such as Bugs and Fixes, Design Principles and Coding Techniques, Refactoring, and Tests/Testing/Testers. There's a couple great sections on softer skills such as learning/continuing education and customer interaction. I was really impressed that the testing section was so long with such great content in it.

Nearly every article in the book was highly useful to me, but a couple highlights would have to include:

* Bob Martin's The Boy Scout Rule on leaving code better than you found it
* Steve Smith's Don't Repeat Yourself on keeping duplication out of your design and code
* Jon Jagger's Do Lots of Deliberate Practice on how to improve your skills
* Paul Homer's Simplicity Comes from Reduction on the power of deleting code

This book's nicely balanced between highly technical concepts (avoiding Singleton patterns, code metrics) and more general topics (education, scheduling). It's a great addition to your bookshelf

The name of this books says it all. It's about things that you already might know from various sources on internet (rss, blogs, tweets etc.) but they're simply put together and are very nice to read.

It isn't that kind of book that won't actually make you better in programming, but it will make you think about some things from other perspective. Easy reading (definitely not as complicated as e.g Fowler's books) for novice and intermediate level programmers. Language agnostic.

This book does not really teach you much. Some people saying something which you may know or themselves may not be able to do it. And several guys saying several things.