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

by Kevlin Henney

With this book, you get 97 short and extremely useful programming tips from some of the most experienced and respected practitioners in the industry, including Uncle Bob Martin, Scott Meyers, Dan North, Linda Rising, Udi Dahan, Neal Ford, and many more. They encourage you to stretch yourself by learning new languages, looking at problems in new ways, following specific practices, taking responsibility for your work, and becoming as good at the entire craft of programming as you possibly can.

This wealth of practical knowledge contains principles that apply to projects of all types. You can read the book end to end, or easily browse through to find topics of particular interest. 97 Things Every Programmer Should Know is a useful reference and a source of inspiration.

Tap into the knowledge of expert programmers who have earned stellar reputations, learn the basic wisdom every programmer needs, regardless of the language you use, and take advantage of the online presence that has evolved from this book project.

Genres: Programming, Computer Science, Nonfiction, Technology, Software, Technical, Coding

Unknown Binding

First published January 1, 2010

Reviews

[Rod Hilton · Rating 2 out of 5]

"97 Livejournal Posts: Collective Suggestions from 20 Experts You've Heard Of And 77 Random People"

This is a book with 97 tips for programmers, each tip takes up two pages or less, written by different programmers (a few get more than one entry). Here's the problem: 2 pages isn't enough to say anything useful about anything. And taking 97 useless writings and concatenating them together doesn't create a useful one - the size limit of each entry prevents anything from being particularly valuable.

Sure, there are some gems occasionally, but it's mostly the same old stuff everyone knows (write unit tests, learn commandline tools, write good comments, write no comments, refactor, DRY, SRP, etc) and a handful of random crap (learn a foreign language). Hilariously, there are occasional serious computer scientists thrown into the mix - one post goes into a lot of detail about how floating point rounding errors happen, including formulas and mathematics, and his tip is sandwiched between a tip on encapsulating behavior with state and one on contributing to open source (as a side note, I am getting kind of tired of the attitude that open source projects are a great dumping ground for practicing your programming skills, rather than real projects worthy of the same kind of care and consideration as your day job).

"Install Me" wins the award for being the whiniest, most annoying post in the entire pack, it should be mentioned specifically.

In any case, most of these posts are a lot of "trust me" or "based on my experience" - no claims have any real evidence, and no tutorials or suggestions contain useful examples - how could they, with only two pages to work with? Every one of these suggestions should be the central thesis of its own book that goes into greater depth, and collecting 97 book descriptions together does not make a new book.

Here's a good rule of thumb: if you are a writer contributing to a book, and someone asked you to do a 90-minute presentation on your material, could you do it? How about a 60 minute presentation? 30? A 5-minute lightning talk, at least? If your entire contribution can be covered in an elevator ride, it's not worthy of a book.

There are probably 10-15 pages worth of good stuff in here, but even that isn't really very good. Not recommended.

[Todd N · Rating 2 out of 5]

Impulse buy on my Kindle. I stopped reading about half way through because I was hoping to get more specific advice. Most of it was sort of "floss between meals" advice that I already know (and ignore). I'd recommend Pragmatic Programmer or Code Complete 2 instead of this book.

[Igor Tsinman · Rating 4 out of 5]

Про 10 заповедей вы наверное слыхали?! Вроде все логично, вроде все правильно. Но только в теории. В книжках. а вот на практике, в жизни все почему-то не так.

Вроде и родителей любим, и врать не хотим, и до чужих жен дела нам нет. Ан нет, на деле все не так гладко, чтобы не сказать грустно (но это не про нас, правда?).

Так вот "97 Things Every Programmer Should Know" это те самые заповеди, только для программера. Прочитать их стоит, к тому же ребята пишут легко и просто. Заповеди коротенькие, одна-две странички. Все по делу, все правильно. А в жизни? Ну, вы свои супер проекты сами знаете. И их состояние (проектов, кода, тестов, документации и т.д.) тоже (а вот это уже про нас).

В книге два оглавления, по нумерации страниц и по темам. Так вот оглавление по темам мне очень понравилось. Системный подход!

Состав со-авторов мне показался слабоватым. Только два корифея индустрии. Среди со-авторов подозрительно много норвежцев. Я не знаю с чем это связано. И ещё одно замечание: в списке со-авторов плохо (практически никак) представлено сообщество Open Source. В нескольких местах откровенно неправильно трактуется GPL лицензирование и т.д.

[David · Rating 4 out of 5]

This is a provocative title! What practitioner in any field could see a title like "X Things Every Y Should Know" and not wonder, "Do I know all of these X things? I should know them all, as I am, indeed, a Y!"

Really far more than just "Things", this is a collection of good advice. Interestingly, it's good even when (perhaps especially when) it is contradictory.

I believe it is wise to pay attention to good advice. I believe it is even wiser to be able to choose the right advice to follow at the right time.

This is the sort of book I think every programmer should read on a monthly basis. It doesn't have to be a book, of course. It can also be articles like Joel Spolsky's 12 Steps to Better Code or Dave Thomas' Code Kata.

If you've been a programmer for a while, the vast majority of the advice in this book should merely reinforce that what you're already doing is correct. If not, you'd be well-advised to take it seriously.

A certain percentage of the tips here are not going to apply to your specific situation. If you're not working on a project with a traditional "build" you can ignore advice relating to automating the build and refactoring the build. If you are a solo developer, you can ignore the advice about pair programming. While you can ignore it, I recommend reading the advice anyway. It only takes a few minutes and you may learn something interesting. Who knows, you may wake up tomorrow and somehow find yourself in a team working on an application with a nightly build! You'll be all set.

One of the most interesting (to me) subjects that cropped up several times in the course of the book is the idea that you can take good ideas in other languages and implement them in the one you're using.

For example, functional programming is all the rage right now, and for good reason. Functional programming creates predictable "no side-effects" code which is especially useful in programs with asynchronous, concurrent, or parallel execution. But you don't have to use a functional language like Erlang or Scheme to pull of functional programming techniques. Code without global variables and functions with predictable return values can be written in practically any language.

Of course, to capitalize on this idea, just reading about it will get you nowhere. That's why we have the advice to learn a new programming language often!

Much advice concerns creating beautiful, simple, elegant code with function and variable names that clearly describe their purpose. Also, how to use comments effectively (say something the code cannot say). I completely agree with these points. For more on this subject, I can think of no better book than Code Complete, Second Edition. It deserves a re-read every other year or so.

A lot of the authors stress variations of "keep quality high." It's easy to let things slip at various points in the development process, especially under tight deadlines. Robert C. Martin perhaps best sums it all up in "The Professional Programmer" in which he describes a doctor performing a hypothetical open-heart surgery. Do you want him "...rushing and making a mess? Do you want him to say, 'I'll go back and fix this later'?" I'm also reminded of Don’t Live with Broken Windows from the book The Pragmatic Programmer: From Journeyman to Master.

Some advice is extremely general. I like "Do Lots of Deliberate Practice" by Jon Jagger. The idea is that if you perform about 10,000 hours of deliberately practicing to improve your ability to do something (like programming), you will master it. Deliberate practice is not just doing something to get it done, but attempting to do it better than before. Mastery is not easy, but it doesn't take any particular innate talent and it is certainly worth the attempt.

Jagger has another excellent article "Make the Invisible More Visible." It's the idea that without visible progress in a project, perhaps there has been no progress at all. It sounds very Zen, but he has some sound reasons for this philosophy and ways to make progress visible!

Several authors advocate reading other people's source. This is good for learning not only what to do, but also what to avoid. If someone else's source is hard to read, why is it hard to read? Try to avoid doing that in your own code. Speaking of reading other people's source, "Fulfill Your Abmitions with Open Source" by Richard Monson-Haefel not only explains why you should join an open-source project, but also has some great specific ideas how to join.

General advice I agree with wholeheartedly and are already part of my development philosophy: "Hard Work Does Not Pay Off" by Olve Maudal and "Reinvent the Wheel Often" by Jason P. Sage (sage advice indeed, ha ha). Sometimes it's just nice to hear someone who agrees with you.

To be perfectly honest, I'd heard all of this advice before. So why do I think it was so valuable to read it again? Because if I'm equally honest, I haven't heeded all of it as well as I might. It has shown me where I have room for improvement. Like my embarrassing lack of automated testing/unit testing! I'm taking all of the ideas from "Take Advantage of Code Analysis Tools" by Sarah Mount to heart.

"Before You Refactor" by Rajith Attapattu probably contained the stuff I least wanted to hear, but needed to. It's a list of reasons not to refactor or restructure and rewrite code. I'm not sure any programmer wants to hear this. But the reality of the matter is that Rajith is right - existing code is often tested, working code. It may be ugly, but it's valuable. I think Joel Spolsky has one of the best articles about this, Things You Should Never Do, Part I.

I'm also guilty of writing features because they're fun or I might need them later on. "Improve Code by Removing It" by Pete Goodliffe explains the YAGNI principal ("You ain't gonna need it").

Two authors also stressed the value of using domain-specific types (most often taking the form of custom classes) in place of system types to eliminate whole rafts of data validation pitfalls. This is an idea I probably haven't applied enough (I make domain-specific types all the time, but I rarely create them for data validation alone).

Some of the articles don't work well, and I think it's most often those with poor examples or no examples at all. Sam Saariste's "Resist the Temptation of the Singleton Pattern" suffers from this. His points about the dangers of using singletons (guaranteed single instances of an object) are well taken. Essentially, they're gussied up global variables. But without a single example showing an instance in which a singleton could have been replaced with another construct, it's kind of like saying "don't write bad code."

A few of the articles were so specific that they failed to be generally useful. Chuck Allison's "Floating-Point Numbers Aren't Real" makes a good point about the accuracy of floating-point numbers when approaching the limits of their capacity. But it seems to me that this could be supplanted with more general advice about the foolishness of getting that close to the limits of your data type for the sake of efficiency in the first place.

It's interesting that none of the authors were concerned with over-engineering or over-analyzing a problem. It seems everyone agrees there's just no such thing as putting too much thought into programming.

[Luboš · Rating 3 out of 5]

Short, easy to read and available for free. But maybe too obvious. Probably for younger me or the industry improved a lot since the book was written.

Several articles worth reading even for software veterans


The Boy Scout Rule by Uncle Bob
Act with Prudence by Seb Rose
Automate Your Coding Standard by Filip van Laenen
Beware the Share by Udi Dahan
Check Your Code First before Looking to Blame Others by Allan Kelly
Don't Be Afraid to Break Things by Mike Lewis
Encapsulate Behavior, not Just State by Einar Landre
Keep the Build Clean by Johannes Brodwall
Prefer Domain-Specific Types to Primitive Types by Einar Landre
Ubuntu Coding for Your Friends by Aslam Khan

[Stefan Kanev · Rating 3 out of 5]

If nothing else, it's an aptly named book.

It does indeed contain 97 things every programmer should know. Sadly for me, I knew pretty much all of them. I still managed to find some interesting ideas or some very nice formulations. I tried to imagine how this book will appear to a novice programmer and I think it might be useful. I certainly wish that the novice programers I've worked with knew that stuff.

Each thing is a two page article on a specific subject. For example:

- Write Tests for People
- The Single Responsibility Principle
- Simplicity Comes from Reduction
- Resist the Temptation of the Singleton Pattern
- Reinvent the Wheel Often

This is great, because it makes the book very easy to drop at any point and pick up again later. Unfortunately, there are two downsides – two pages are not enough to go into sufficient detail on most subjects and the random switching of subjects makes it hard to remember most of the book after reading it.

I intend to pick it up every now and then to read a "thing" or two.

[Mark Seemann · Rating 3 out of 5]

After having first read 97 Things Every Software Architect Should Know, I at least found this one more interesting.

As could be expected, the Every [...] Should Know part of the title is quite a stretch, but there's some good advice here and there.

I would have expected more stuff like Understand the difference between a decimal and a floating point number, or Beware of invisible unicode points, such as byte-order marks (cost me half a day, once), but most of the articles were focused on the (inter)personal aspects of software development, more than actual programming. In all, I think I counted three or four articles that contained any code at all.

Large parts of these books I read on planes, subways, etc. and they fit such scenarios quite well, but if you have time to sit down and do some serious reading, you'd be better off with one of the software classics.

[Jakub · Rating 2 out of 5]

for beginners maybe. but i did not learn anything from it. some chapters are about the same thing with different title. basically if you are in dev for more than 5 years - don't wast your time on it.

[Stillo · Rating 3 out of 5]

Dość krótka pozycja o wskazówkach dla programistów, w sumie nie nauczyłem się nic nowego😅 ale do zabicia czasu na uczelnianych korytarzach spoko

[Fotis Koutoulakis · Rating 4 out of 5]

This contains quite decent advice on software engineering in the form of small (blog post-like) articles on various topics.

A developer early in their career will get the most out of it (I already knew everything but enjoyed some of the takes/framing).

Only disadvantage is that the book jumps between multiple topics and doesn’t follow any specific structure, which might make it a bit of a challenging read for those who prefer to consume in a more structured way.

[Wanasit · Rating 2 out of 5]

I don’t like the book. I didn’t learn much from reading it.

It’s not the authors' topics that are bad, but reading 97s of 2-page random things is a bad way to gain deep programming insight. I could do better reading some programming blogs on the internet.

For example, comparing reading the “Clean Code” vs reading three things in this book written by Robert C. Martin. As a person who already finished both, I learned almost nothing from the latter. This book is pretty shallow on the topics.

[Martynas · Rating 3 out of 5]

Too short, most of these aren't even concise, just naming and describing the problem or idea but not delivering actual advice. It's more like a guideline checklist for beginners (though i know experienced developers, who don't follow most basic principles listed here) on what to dig deeper.

[Deniz · Rating 2 out of 5]

I have to say the book is quite outdated. I did not find it useful at all, at times I even found it annoying and boring.

There might be a few useful suggestions if you are new to the industry but if not avoid reading it.

[Diamantis Antoniou · Rating 2 out of 5]

Not to much info if you're an experienced developer
General advice for juniors

[L · Rating 3 out of 5]

The "Beware the Share" chapter by Udi Dahan resonated with me. I also now buy into version control.
p. 14
"It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature, I took extra care to put in place everything I had learned - commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt so ready for came as a rude awakening - reuse was frowned upon!"
"How could this be? Throughout college, reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who had taught me - was it all wrong?
"It turns out that I was missing something critical.
"Context.
"The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those four lines of similar code were accidental - a temporal anomaly, a coincidence. That is, until I came along.
"The libraries of shared code I created tied the shoelaces of each foot to the other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.
"While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical - had they been localized, the sharing may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system, even though the code itself looks just fine."

[Ashish]

I started reading this book with fair amount of skepticism. Just looking at the cover, it is hard to miss how a large percentage of contributors are white and/or male. It has also been 9 years since the book came out and there has been quite a few changes in how the industry operates and the kinds of technology people are working with. There were definitely essays that probably were very useful at the time they were written and the advice wasn't followed as broadly but industry has improved and the advice these essays were giving are part of most projects now.

The fact that awful human being extraordinaire with extremely shitty worldview like Robert C. Martin had been given the chance to publish not just one but three essays was probably top of the list. Good news is that last reason was a valid one. His contributions in this anthology, much like his worldview, is no longer relevant but he is too stubborn to acknowledge it or put in effort to change himself. Good news is that we can ignore him.

There are definitely chapters in the book that either are more applicable to contexts in which I don't operate or were too specific to either a technology or a paradigm that they did not resonate with me. So the second reason for skepticism was somewhat justified but I was pleasantly surprised to find gems that have withstood test of time. A common theme for the essays that seemed timeless and relevant was that they were generally considering human side of our profession and giving it proper credence. These are very different from the types of essays that I find unnecessarily prescriptive and moralistic, a form of writing Robert C. Martin is known to use which makes him extremely unapproachable and unfortunately some other authors have chosen to follow as well.

There are definitely certain essays that are useless mostly because they are delivered from a position of privilege while being completely unaware of how what you are recommending only works for you because you enjoy certain privileges. A lot of these essays basically regurgitate poorly advice from the Pragmatic Programmers of learning one new language every year and others like it. It could very well be that because I don't like to learn random technology just for the sake of learning it and I get most of my pleasure in problem solving from being seeped into context and knowing whose life I am improving with my work, I find advice like that less than useful. It also is a sign that the author has not examined their privilege, access, and other things that make these advice extremely limited to only those who share that. Of course, being white dudes (it's almost always dudes), they rarely acknowledge it in the work and dispense the advice as if it is universally applicable.

With that said, if I were to recommend chapters from the book to folks, they would be the following (in the order they appear on the book):

1. [Code in the Language of the Domain](https://github.com/97-things/97-thing...)
2. [Convenience Is not an -ility](https://github.com/97-things/97-thing...)
3. [Don't Be Cute with Your Test Data](https://github.com/97-things/97-thing...)
4. [Don't Rely on "Magic Happens Here"](https://github.com/97-things/97-thing...)
5. [Encapsulate Behavior, not Just State](https://github.com/97-things/97-thing...)
6. [The Guru Myth](https://github.com/97-things/97-thing...)
7. [Hard Work Does not Pay Off](https://github.com/97-things/97-thing...)
8. [Keep the Build Clean](https://github.com/97-things/97-thing...)
9. [Learn Foreign Languages](https://github.com/97-things/97-thing...)
10. [The Longevity of Interim Solutions](https://github.com/97-things/97-thing...)
11. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](https://github.com/97-things/97-thing...)
12. [Missing Opportunities for Polymorphism](https://github.com/97-things/97-thing...)
13. [Pair Program and Feel the Flow](https://github.com/97-things/97-thing...)
14. [Prevent Errors](https://github.com/97-things/97-thing...)
15. [Put the Mouse Down and Step Away from the Keyboard](https://github.com/97-things/97-thing...)
16. [Read Code](https://github.com/97-things/97-thing...)
17. [Read the Humanities](https://github.com/97-things/97-thing...)
18. [Start from Yes](https://github.com/97-things/97-thing...)
19. [Take Advantage of Code Analysis Tools](https://github.com/97-things/97-thing...)
20. [Test for Required Behavior, not Incidental Behavior](https://github.com/97-things/97-thing...)
21. [Test Precisely and Concretely](https://github.com/97-things/97-thing...)
22. [Thinking in States](https://github.com/97-things/97-thing...)
23. [Two Heads Are Often Better than One](https://github.com/97-things/97-thing...)
24. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](https://github.com/97-things/97-thing...)
25. [Ubuntu Coding for Your Friends](https://github.com/97-things/97-thing...)
26. [Write Tests for People](https://github.com/97-things/97-thing...)
27. [Your Customers Do not Mean What They Say](https://github.com/97-things/97-thing...)

It is quite coincidental that I picked 27 things every programmer must know :).

[Galileo Valiente · Rating 5 out of 5]

If you are an experienced programmer already, the lessons in this book might be known to you already but it never hurts to know these ideas even if it simply validates what you already believe in. If you already know all these, then you might probably be leading rookie programmers, so save yourself time and tell them to read this book before their rookie mistakes become your responsibility.

Sure this book is not be-all and end-all of programming but it does give you the foundations on what to look out for. Knowing other programmers problems that you have not seen before would make you think of possible solutions that they offer or perhaps it can be a catalyst for you to device your own solution.

I wished I've read this book during my early days of programming. It is full of nuggets of wisdom from these accomplished people that I only later knew by falling into these traps and having experience give me the hard lessons. Reading them now makes me think -- "Now you tell me!". Many of the lessons here are not new to an experienced programmer but you don't have to wait to experience it yourself because that could be expensive and career limiting.

This book is highly recommended for those who are just starting to make programming a career or even just planning to be one. It will save you time and money in the long term simply because you learned from the experiences of those who've been there already. They share it so that you don't have to bear the pain later on.

[David · Rating 2 out of 5]

If you bought this, then you've wasted money, regardless of your level of expertise.

If you're a novice who's just starting out or a developer who wants to find out more about best practices, find books that target the areas you're looking to improve on; they will be way more useful by providing concrete and specific examples.

If you're an expert looking for a refresher, just about any software development blogs, sites, or forums that you've been following (you are doing this, right?) will give you better value.

The 97 things are each told in a max of 2 pages - very little room for anything more than a generic discussion. They range from common sense and popular practices to technical challenges and domain expertise. I doubt any professional developer would find even half of these immediately relevant and applicable to their current work/role. They just cover too many areas in too few details.

I'm not saying the advice is bad (although I did find myself shaking my head at a couple), most are good valid advice - I'm just saying this is a poor way to acquire them.

[Ashraf Bashir · Rating 2 out of 5]

Two pages per article, are not enough to discuss any point/issue! Due to this small article length, the book suffers from lack of code snippets, yup as you expected, just to save space!, so ideas are totally abstract without any practical samples (except 4 or 5 articles) ... Moreover, many topics are replicated more than 2 times with exactly same ideas, words and expressions ! And some of them contradict each other (is it bad or good? mmm, honestly I don't know) ! ... Also the collection is not organized by topic, so you keep zigzagging from topic to topic then back to initial topic without any logical flow ... Despite this, some articles are very useful, but they are few, no more than 10% of the total number of articles (i.e. around 8 or 9 articles are worth reading) ... Overall, don't waste your time reading this book, just follow any newbie technical/programming blog, and you will get more info than what you may get from book. Not worth reading.

[Joel · Rating 3 out of 5]

If you're a programmer, you should definitely read this book through at least once. I'd say about 25% of the book was not directly relevant to me, 50% was something I was already quite familiar with, but that remaining 25% was excellent material that made me think in new ways. Each essay is only 2 pages, so you won't go in-depth on any topic, but it will hopefully spark your desire to learn more.

One critique of the book is how it's organized. It appears that the 97 items are simply listed alphabetically by title. Grouping these into logical subjects would have made more sense I think.

[Logesh Paul · Rating 3 out of 5]

97 tips from experienced professionals (two pages each) about the software development process in general.

The tips cover a large variety of topics: programming, debugging, code review, deployment, testing, self-improvement, attitude, design patterns, communication, performance, DRY, etc.,

It's not very detailed, best suitable for intermediate programmers. Some of the topics (like version control, commit history, comments, testing, agile, etc.,) may act as a quick refresher for advanced programmers.

[Adam · Rating 3 out of 5]

The book lacks something which would glue those 97 pieces together. It isn't well-structured and some things are already outdated. 97 Things might be good for a beginning programmer to show him what he already knows and what issues should he read about. All information are very brief and to get a good grip on the selected topic you must search for some other books.

[Alamin · Rating 5 out of 5]

A must read for programmers. after reading 2 or three pages you will start to like it.

[Thiago · Rating 4 out of 5]

I really like books with these small tips for your daily basis work, you start using it without even realising, which is great and this book is one of these.

“97 Things Every Programmer Should Know” is a book that each single “Thing” is written by a different author, and these authors are some very well known developers in the industry.

These are my favourites notes from this book:

Technical debt is like a loan: you benefit from it in the short term, but you have to pay interest on it until it is fully paid.

Chapter 1. Act with Prudence - Seb Rose

Well, we all have faced technical debt but we should really avoid it to the point that it starts getting hard to add new functionalities to the code or to even refactor the code. It’s really important to understand the right time for a code refactor, otherwise the code might become really hard to support, so difficult that even small changes can have a bad impact. If this is already the case, you should really consider refactoring it. The longer you leave it, the worse it gets.

Beauty of style and harmony and grace and good rhythm depends on simplicity. - Plato

Chapter 5. Beauty Is in Simplicity - Jørn Ølmheim

“Betcha can’t guess what it does!“he crowded

Chapter 58. A message to the Future - Linda Rising

People write software with people for people. It’s a people business.

Chapter 71. Read the Humanities - Keith Braithwaite

There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies.

Chapter 81. Test Precisely and Concretely - Kevlin Henney

It’s always good to keep in mind that we write code for people to understand and that comes with simplicity. I always like to think that if something is too complicated, there might be a simpler way to do it. It’s usually easier to make something complex than to make something simple.

Consider the best programmer you’ve ever met: at one point, that person knew less about software than you do now.

Chapter 36. The Guru Myth - Ryan Brush

It’s always possible to achieve more and to learn more, that’s one of the things that I like the most about technology: it is constantly changing and evolving and so should we.

Summarising, this is a great book with some very useful tips for good practices in Software Development that in fact every programmer should know.

[The Lost Dreamer · Rating 2 out of 5]

Easy to read collection of short assays aiming to pep-talk naive programmers in a mostly friendly way. Sure, there are some interesting and even enlightening lessons one can extract from this. That's why I started it and mostly, why I finished it. But there are too many cons in this book: first of all, less than five of its 97 assays are written by women. Probably this is heavily linked to its second main problem: it hasn't aged well. Most of the guys who write it feel like dinosaurs nowadays. But that's no excuse: not considering that women wrote code ten years ago was and still is part of the problem. And for me (a female programmer) it's a paramount reason why I'm not taking this book very seriously.
Also, despite the occasional page where some valuable piece of knowledge is shared, most of the book is written from the perspective of a senior code developer that thinks his word is the law written on stone. Many of the advices are quite contradictory, in fact, and most of the time it fails to provide any really useful skill that helps a code developer navigate the harsh waters of a development team.
It's sad to see that there isn't a single assay that encourages developers to straighten their communication and other soft skills. But, of course, highly harmful messages like 'you'll only be good at this if you put a ton of extra hours in it' or, simply put, 'do what you're told, do it fast or prepare to be fired' are even repeated more than once.
In the end, this is a sad book that I wouldn't recommend to anyone, despite de occasional pearls of wisdom it contains. Fellow coders: talk with your co-workers, learn from your peers and write clean and useful code that makes you happy to read back. But never, absolutely ever, buy the crap many of these so-called seniors are trying to sell here.

[Florentin Cosmin · Rating 3 out of 5]

This book contains 97 tips from experienced professionals about the software development process in general, each one succintly described in less than two pages.

The advices cover a large variety of topics: programming (pay attention to the warnings also, learn the tricks and shortcuts in your IDE, design a readable API for your methods, have separate exception handling for framework and bussiness logic exceptions, write only usefull comments), deployment (deploy the solution early and often, avoid different versions for different environments), testing (automate your tests, make scripts to run tests after hours), continuous improvement (listen to technical podcasts on your commute, learn a programming language every year), design patterns and SOLID principles, general advice about communication inside a software development team and even some tales about the history of software engineering.

Since these are just general advice, the authors ca not go into much depth explaining the topics and the continuous change of the context and lack of a central idea are making this a bit harder to read. However, if you feel you resonate with some authors, you can search for some other work of theirs later on.

[Reza K. · Rating 3 out of 5]

well, this book consists of 97 two-page tip and experiences about software development. some are about habits, some are about best practices, some are about the way you should look at things, etc. it was of course worth reading. somehow i can say it is essential to every programmer. but of course there's a best-time-to-read-this-book. I think coders with less than 1 year have some more important stuff to do: work. the things mentioned in this book will have their best effect, when the reader has been out there working for a while, to me: at least six month-full time. before that, although some of the tips still can be useful, but you will miss many aspects of them, just because you are reading the solution about a problem that you haven't met yet.
to sum up: this is a really useful book, written as simple as possible (not like those convoluted books that make you struggle understanding every sentence.) and it sure has gather some great wisdom together, about all aspects of software development.

suggestion: considering what I wrote above, this book will make a great gift to your friend/colleague in their one-year-anniversary as a developer/programmer.

[Eric Mesa · Rating 4 out of 5]

I think this book is best read by someone who's been in the software field for a few years - it provides the perspective to truly understand what the Experts are communicating. I think a recent CS grad could certainly understand the words and concepts, but would be lacking the perspective of working in the real world with real life-cycle requirements and customer requirements and time crunches.

I learned a lot - things I want to incorporate into my professional and personal coding. The nice thing is that each of the 97 Things is about a 2 page essay. It's very easy to set yourself to read a few during your lunch break without getting overwhelmed by a whole chapter on any particular topic.

[Ali Izadi · Rating 3 out of 5]

These kinds of books have a major problem: Because it contains words from different people, it doesn't have a specific structure and connection between its parts and after reading it just some keywords remain in your mind. But in general, it is useful because you understand important subjects in programming that you should learn but surely you feel that you need another sourcebook to follow that subject and efficiently learn it. I recommend this book for undergraduate students who want to start a job and for juniors who feel the necessity of learning new concepts in software engineering to enhance their skills.

[Ignacy · Rating 5 out of 5]

It's true that each tip is max two pages long and one can't go deep in a few paragraphs. Many see it as a weakness, but for me it's the strength of this book. In my experience programmers learn by making small steps every day - in pair/mob programming or code review, by approaching and solving new problems.

Each of the tips in the book can be read during the morning coffee and tried the same day. After 100 days one will be a better programmer for sure.

That's the opposite of reading 200 hundred pages, in-depth book and usually not being able to use gained knowledge any time soon. Or not seeing value in incorporating advanced techniques while simple solutions will suffice.