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.

Many people don’t realize the insecurities in email. First, the connection to send and receive email is not encrypted by default. Certain hosting companies, like Joyent, require encrypted connections by default. Of course, this makes setting up email clients a bit trickier, hence why the average joe-sick citizen is not going to configure their client to use it. With the connection left unencrypted, anyone eavesdropping on the wireless signal or over a wired hub connection (like some cable companies use) will be able to pick up the username and password credentials for your email account. They can then get into your account, read your email, or send email from your name. Some people don’t see this as a privacy concern. I say those people need to wake up and listen to identity theft stories.

The second problem with email is that the transmission of the email content itself is not encrypted. If you solved the first problem I mentioned, that secures the connection and transmission of the email content between yourself and your hosting company. The second part of the transmission is between the hosting company and the rest of the Internet until it reaches the target host. The problem here gets a bit technical, but a simple explanation is that there is no one path to a target host over the Internet. Remember, the Internet was developed to withstand a nuclear war, so your data will travel is any direction as long as it makes its way to the host in a reasonable amount of time. When the data is traveling through the Internet, bouncing around different intermediary hosts, that data is unencrypted and anyone can view the data if they have the technical skill (it doesn’t take much). So all of your information sent between your doctor and yourself is now being broadcast to everyone on your continent. That’s not violating doctor-client confidentiality but it’s getting pretty close. If you don’t think this is a privacy problem, then why did you traditionally go to the doctor and speak to them personally in a small room with no one else around?

The solution to the second problem is difficult and requires a lot of technical skill, especially with today’s email clients. You need to configure your email client to encrypt and sign your messages with a digital certificate (also known as public key cryptography). The problem with this is two-fold: first is that the sender’s email client needs to configure correctly, which is often difficult to do because each client is configured differently. The second problem is that the receiver’s email client needs to be configured correctly to check the signature and decrypt the data with their own private key. If your eyes are going sideways now, just wait until you set it all up. Email cryptography is still too difficult for the average person to configure, so by default people are not going to use it. That is going to leave a lot of people with medical conversations out in the open.

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.