In speaking with my mentee today, he asked whether I had any recommendations for real-world programming books.  I had to think about this question for a minute because of its apparent misdirection.

Typically, any real-world programming is done with a variety of languages, so I can’t just pick out the books that I have used to learn languages in the past.  These books have been obsoleted by newer versions of the language.  But that is where the misdirection comes in; why should we look at programming languages when it is the art of programming that is more important in the professional world?  And so, I came up with this rather short list of my favourite books that teach a programmer how to be a better programmer.

Mythical Man-Month

This books mainly focuses on how software projects are different from construction or other types of projects.  The content is taken from a real-world software project and helps the student to understand that professional programming has a lot more to do with communication and politics than it does about the act of typing code into a computer.

The Pragmatic Programmer

This book focuses any student programmer on the tools necessary to use in the workforce.  It may not be the exact tool being used by a company, but focusing on one tool allows you to understands its benefits and limitations.  Also, things that are rarely used in school, like version control, are discussed as necessary tools for any student.

Refactoring: Improving the Design of Existing Code

This is a quintessential book for taking legacy code and modifying it to increase speed, reliability, readability, etc.  I have seen a lot of programmers who have not cut brand-new code for months on end, instead relying on legacy code fixes and upgrades to fill the void.  Working with legacy code typically sucks, because it was developed by someone else and, invariably, has little documentation or readability.  The maintainer has probably left a long time ago, leaving you with nothing more than the code to understand.  While working on legacy code, there may be better, faster ways to write the code or to decouple libraries from the core modules.  This will help in the future should a library need to be upgraded or replaced by another third-party.

Clean Code

In keeping with the previous theme, this book helps your descendants understand your soon-to-be legacy code.  Readability of code is key, and this book highlights real-world examples of inefficient, unmaintainable code.  Out of all the books on this list, this is one of the easiest books to devour, and even seasoned programmers should find this book a good refresher on good and bad habits.

Patterns of Enterprise Architecture

I found this book to be useful when I started using interpreted languages like Python and Ruby.  Specifically, Ruby on Rails uses patterns from this book extensively.  For example, Rails uses an ORM called ActiveRecord, but I hate just taking someone’s word for it that it is going to work for me.  I found out that the ActiveRecord pattern is taken from this book, and I was able to understand the history and meaning of it.

Design Patterns: Elements of Reusable Object-Oriented Software

More companies these days are using design patterns in their code.  These patterns are simply best practices that have been vetted by some of the best programmers in the world.  After reading this book many years ago, I found it to help with understanding the common coding practices.  In professional programming, you are going to write the same type of code repeatedly, but for different projects, so these design patterns help to consolidate those repetitious code snippets into meaningful names.

…after all, how would you know?

Batch processing typically involves moving large data files (so called extracts) between systems. These data files include can include financial information, billing information, reports, blah blah blah. The thing I see very often is the verification and authentication of extracts…or rather, the lack of it. I believe in the Bruce Schneier school of learning, where one must be born with the security mindset, as it cannot be learned. As a result, I’m always seeing exploitable problems where others just see efficiency.

The problem I see currently with moving large data files around is that the files are never verified as being complete. Sure, the transfer protocol being used by the underlying operating system says that it does a completeness check, but what if the file was tampered before it was sent? Whether these files move into different directories or over the network, they must be checked each time for completeness and authenticity. A simple solution to all of this is to use checksums, which has been the solution for authenticating downloadable Internet files for many years.

So if checksums are such a simple concept and have been around forever, why don’t all companies use them? The first is money. It takes more development to put in extra checks around the transfer of files, which in turn means a higher cost to the company. Second is that there is a lack of security-mindedness in code development today. This isn’t just about checking that your code is safe from SQL injections, this is about making sure that no part of the system can be subjected to exploit.

Here’s a real-world example. Instead of thinking of transferring extracts between systems, let’s translate that to money between transferred between a bank’s branch offices to the central hub. Since digital money or sci-fi credit systems do not yet exist, the money must instead be transferred by armoured vehicles. So which is the best place for someone to exploit? The banks can have the most secure environment possible, but they must give up some of their security during transport. This is a reasonable risk because there are numerous verification protocols in place before the money leaves and after it has arrived at the central hub.

Bringing the example back into our problem at hand, there is an inherent risk to sending extracts to another directory or over the network. The target filesystem can fail, the network can be sniffed, the target machine can be a zombie. Secure communications can mitigate that (MITM attacks aside) but one can never be certain if the files sent are the exact match to the files received.