97 Things Every Programmer Should Know.
By Kevlin Henney –
Reviewed by Martin Lavin
97 Things Every Programmer Should Know is a collection of short, two page essays, each by an experienced, sometimes famous programmer. The book is a collection of tips and tricks for writing code. The essay summaries below are some of my favorites.
Pair program and feel the flow
Author: Gudny Hauknes
I did not think pair programming is such a great idea, I thought it was kind of a fad. However, this essay has encouraged me to take a second look.
When a critical developer leaves the team, the other paired developer can help prevent the project from being dead in the water. The remaining developer can fill in much of the shared knowledge, continuing the flow and help revise the new estimate. Another set of eyes with knowledge of a problem or new fix, is always helpful.
Personal pride/competition will encourage the best work possible.
Know how to use Command-Line tools
Author: Carroll Robinson
Command line tools and scripting can be very powerful and allow one to do things an IDE cannot. For example the search and replace capabilities provided by the grep and sed utilities are often more powerful than those found in IDE’s like Eclipse or Microsoft Visual Studio. Ruby on Rails programmers usually make much use of the command line and are aware of its’ power. Other programming languages/frameworks not so much!
Learn to Estimate
Author: Giovanni Asproni
As a programmer you need to know how to estimate how long it will take to complete your coding assignment. Estimating tools help, but experience helps the most. Break the project into small chunks and have crystal clear communication with all parties on what the deliverables are. Watch for scope creep. Most estimates are underestimated by quite a bit. DO NOT make an estimate on what you think your manager/customer wants, or what you think will make her happy. Your reputation is at stake! As Steve McConnell writes “The primary purpose of software construction is not to predict a projects outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them”.
The Professional Programmer
Author: Robert C. Martin (Uncle Bob)
The single most important trait of a professional programmer is personal responsibility. If you are a professional, then you are responsible for your own career. Craftsman and professionals of all types keep up with the latest tools and knowledge. Doctors and Lawyers train themselves on new knowledge and tools in their fields. We should too. A good example of this is Ruby on Rails. It is a great new language/framework/development tool, along with new and better IDE’s, debuggers, text editors and computers. We take responsibility for the code we write, it is tested and works. Professionals are team players, they help each other.
Software professionals do not rush their code. Doctors do not rush on the operating table, how ridiculous. Lawyers are prepared for the case and do not rush when explaining to the jury(they might get sued). Rushing for deadlines, especially while tired; creates buggy inelegant code. This should not be new to anyone!
Hard Work Does Not Pay Off
Author: Olve Maudal
As a programmer, you’ll find that working too hard does not pay off. You might fool yourself and a few colleagues into believing that you are contributing a lot to a project by spending long hours at the office. But the truth is that by working less, you might achieve more, sometimes much more. If you are trying to be focused and “productive for more than 30 hours a week, you are probably working too hard. Consider reducing your work load to become more effective and productive.
This may seem counter intuitive, but it is not. Many famous studies bear this out. The essay explains in much more detail. Do doctors or pilots perform surgery or fly planes 60 hours a week? Of course not. Education, preparation and change are necessary. Managers/programmers should be realistic about our craft/profession/science.
Probably not a good book for experienced programmers. Most of the essays are about subjects that most experienced programmers already know or have read about. However, readers at the novice to intermediate levels would certainly benefit. I enjoyed reading it.