Based on the original concept of “97 Things Every Programmer Should Know” developed by Kevin Henley, Shirish Padalkar presents in the book “97 Things Every Programmer Should Know – Extended” 68 essays about software development that were part of the original project, but were not selected to be included in the first book.
This book is very easy to read as each author develops his idea in two or three pages. You can therefore read it sequentially or pick the most interested topic for you in the table of content. The topics range from learning from failures to source code documentation or UI decoupling. Providing an insider opinion about the topic discussed, all these short essays reach their primary goal: make you think about your current software development practices.
I will recommend reading “97 Things Every Programmer Should Know – Extended” to every software developers and testers or any person involved with software development.
Reference: 97 Things Every Programmer Should Know – Extended, Shirish Padalkar, Leanpub, https://leanpub.com/97-Things-Every-Programmer-Should-Know-Extended
Quotes
It may sound amazing, but you could be a better programmer if you were both lazier and more stupid. First, you must be stupid, because if you are smart, or if you believe you are smart, you will stop doing two of the most important activities that make a programmer a good one: Learning and being critical of your own work. If you stop learning, it will make it hard to discover new techniques and algorithms that could allow you to work faster and more effectively. If you stop being critical, you will have a hard time debugging and refactoring your own work. In the endless battle between the programmer and the compiler, the best strategy for the programmer is to give up as soon as possible and admit that it is the programmer rather than the compiler who is most likely at fault. Even worse, not being critical will also cause you to stop learning from your own mistakes. Learning from your own mistakes is probably the best way to learn something and improve the quality of your work.
Some people say that refactoring is waste in the Lean sense as it doesn’t directly contribute to the business value for the customer. Improving the design of the code, however, is not meant for the machine. It is meant for the people who are going to read, understand, maintain, and extend the system. So every minute you invest in refactoring the code to make it more intelligible and comprehensible is time saved for the soul in future that has to deal with it. And the time saved translates to saved costs. When refactoring you learn a lot. I use it quite often as a learning tool when working with unfamiliar codebases. Improving the design also helps spotting bugs and inconsistencies by just seeing them clearly now. Deleting code – a common effect of refactoring – reduces the amount of code that has to be cared for in the future.
They say that some people see the glass half full, some see it half empty. But most programmers don’t see the glass at all; they write code that simply does not consider unusual situations. They are neither optimists nor pessimists. They are not even realists. They’re ignore-ists. When writing your code don’t consider only the thread of execution you expect to happen. At every step consider all of the unusual things that might occur, no matter how unlikely you think they’ll be.
Source code that does not contain comments is sometimes said to be “self-documenting.” In reality, there is no such thing. All programs require comments. In an ideal development environment, coding standards and code reviews create a culture that enforces good commenting practices (and usually high-quality code as well). For less-than-ideal environments, where the programmer sets his or her own commenting standards, the following guidelines are suggested.