97 Things Every Programmer Should Know

The 97 series now consists of the following titles:

• 97 Things Every Software Architect Should Know
• 97 Things Every Programmer Should Know
• 97 Things Every Project Manager Should Know

The architect book was very good. The programming topics were also good but I found more value within the architecture discussions. I definitely want to get my hands on the project management book soon. I have a feeling that one will be a bit more humorous.

My Favorite Things Programmers Should Know:

• The Professional Programmer by Uncle Bob
  • Favorite Quote:
    "Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right".
    
    
  • Key Message:
    This post was unquestionably at the top of the my list. The entire message is about personal responsibility. This one's a wall hanger. Print it out, frame it, and hang it up! This post reminded me of the talk I heard Dave Thomas give many years ago at No Fluff Just Stuff.
  
  
  
  
• Don't Rely on "Magic Happens Here" by Alan Griffiths
  • Favorite Quote:
    "You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't."
    
    
  • Key Message:
    Can you fulfill the roles of every individual on your last project? Image how valuable you'd be if you could. Again, the more knowledge you have, the more efficient you and your project will be.



• Hard Work Does not Pay off by Olve Maudal
  • Favorite Quote:
    "programming and software development as a whole involve a continuous learning process."
    
    
  • Key Message:
    Continuous learning is the key point within this post. Combined with the right tools and knowledge you will see greater efficiency gains on your projects. The real challenge is allocating time to focus on your continuous learning efforts.



• First Write, Second Copy, third Refactor by Mario Fusco
  
  • Favorite Quote:
    "So the first time you are implementing something new, write it in the most readable, plain, and effective way. It is definitely too early to put the general part of your algorithm in an abstract class and move its specialization to the concrete one or to employ any other generalization pattern".
    
    "The second time you face a problem that resembles the one you solved before, the temptation to refactor that first implementation in order to accommodate both these needs is even stronger. But it may still be too early. It may be a better idea to resist that temptation and do the quickest, safest, and easiest thing it comes you in mind: Copy your first implementation".
    
    "When you need that solution for the third time, even if to satisfy a slightly different requirement, the time is right to put your brain to work and look for a general solution that elegantly solves all your three problems. Now you are using that algorithm in three different places and for three different purposes, so you can easily isolate its core and make it usable for all three cases".
    
    
  • Key Message:
    The Rule of Three also applies for reuseability. For example, in order for a solution to be classified as a design pattern the rule of three must apply. If you can successfully apply the same pattern across three separate systems you have a design pattern. Furthermore, this rule also applies to API design. If your API can successfully be consumed by three separate clients, you have a very concrete and proven design. Applying the Rule of Three for shared services or libraries is also valuable.