I just read a great quote, that perfectly sums up the type of person, worker, and friend that I strive to be:

“Have you ever worked with a good manager? They’re full of ideas. They’ll suggest, they’ll coach, they’ll recommend. They’ll cajole and beg and plead if they have to. But they won’t tell you how to do your job, not unless it’s a real emergency, anyways. They hired you, they gave you a task they know you can handle, and they trust you to make the details happen.”

Source: http://blogs.msdn.com/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx

To paraphrase what someone smart once said: Sometimes it’s the lazy things in life that count.

Laziness does have it’s rewards, as long as you are sure to pinpoint exactly what you want to be lazy about.  Case in point, long system operations.  Countless times I have transferred files, (un)compressed archives, or performed long operations and forgotten what I was doing while my terminal window was sitting in the background.  I have also had co-workers forget to hand me results because they were distracted by something else, and minutes or hours go by after the system operation has completed.

To solve this problem, you have to think like a lazy person, and how they would combat this situation.  Would a lazy person watch the terminal screen for minutes or hours until the operation finishes?  Absolutely not.  They have more important things to do.  Instead, the lazy person would like to be notified when the processing has completed.  You could send an email, but mail routing can take minutes to complete (and your email client can be set to check mail once every 10 minutes, defeating the purpose).  The next best thing to do is to alert yourself when the processing has finished with an audible alarm.

If you are running Unix or Linux, you can use the command ‘beep’ to have the system send an audible beep whenever you call it.  You can alert yourself when the processing has finished by the following command:


$ someLongOperation.sh; beep


If you are working on a system without the ‘beep’ command, or you are not authorized to install it, you need to write your own script.  Sending a control character to the ‘echo’ command will produce the same results as above.  The script is as follows:


====beep.sh====
echo -en "\007"
====beep.sh====


Now mark this script as user executable and run it.

$ beep.sh

You should hear an audible beep from your computer.  Using this script to mark the end of a system operation is as follows:

$ someLongOperation.sh; beep.sh

This will work so long as the beep.sh is in the current directory or somewhere on your $PATH.

Enjoy and be happy about using laziness to increase productivity.

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.