Wash Your Hands

I mentioned recently that I was back working in corporate America, earning my living as a Java programmer. Part of the experience of returning is seeing what has changed and what hasn’t. Today’s topic is one of the unchanged things.

We have some fairly simple hand-washing guidelines in our home. You wash your hands after using the bathroom, before preparing food, before eating and anytime they get genuinely dirty for some other reason. Not too draconian. I think this shows I’m not some kind of helicopter parent who rushes in with the medicated wipes every few minutes.

It still amazes me that grown men can use the bathroom and then not wash their hands! (I don’t use the ladies bathroom, so I have no data on how that demographic behave in the same circumstance.) Now, I’m not for paranoid levels of hand washing, but I am in favor of some, especially when you are interacting with so many co-workers.

The craziest though are the ones who run some water on their hands and then dry them. This is really bizarre. If they’re going to the effort to be right by the soap dispenser, how do they think it’s a good idea to save ten seconds by ignoring the soap? This is one of the aspects of working in an office building that I did not miss.

Back To Work

After a financial challenge at the church this summer, I am now back to work. No details, sorry. There are some parts of pastoring that are not unlike the making of sausage or the passing of laws, in that you really don’t want to watch what happens during the process.

The good folks at TeamSoft, Inc., here in the Madison area, found me a programming contract and I am now gainfully employed and have been for coming up on three months now. This is my third contract through TeamSoft and I continue to be very happy with them as a contracting agency. It doesn’t hurt that they found me a programming opportunity even after I’d not written a line of Java code for exactly two years! That was impressive. The client, who shall remain nameless to protect the innocent, is actually one that I have worked at before. The Java programming community in this area is very small. There is a non-trivial chance that you’ll either go back to a place or that you will work with former co-workers.

Converting back to being bi-vocational has been challenging. Especially doing so in the fourth quarter of the year when everything gets crazy busy in life, school and church. Sleep and family time have been the worst casualties. I typically leave a little after 6:00am and return by about 5:30pm, later if there are errands assigned to me by The Queen Of All She Surveys. Getting up early has never been my strong suite, so I’m really not on speaking terms with my alarm clock right now.

The contract seems to be going well and certainly I have remembered all of the Java that I thought I had forgotten. Thankfully I was still regularly tinkering with scripting and trying out new esoteric programming languages, so my programming instinct was still strong. The client is still using Java 6, which is the version I was using two years ago. This time the tendency of large corporations to lag behind on their Java versions has worked in my favor. I will learn the new features in Java 7 and 8, but, for this client at least, there is no screaming hurry.

The most interesting thing about this current contract is the number of people who remember me either from previous employers or from my one year here at the client eight years ago. My hiring manager remembered me and so that helped smooth the flow of the interview. I have bumped into former co-workers from four different places. Walking around at work is almost a trip down memory lane every day.

Being out of corporate life for two years gives me an interesting perspective now that I’m back. I see quite a few things with fresh eyes. I’ll write about these as I think of them.

Psalm 150:6 – David’s Last Scripture

Let every thing that hath breath praise the LORD. Praise ye the LORD.
Psalm 150:6

King David had much to say on the subject of the Lord, as the known author of over half of the book of Psalms. The Lord had some important things to say about David. He was described by the Lord as “a man after mine own heart” (Acts 13:22), so it seems clear that David had either an acute understanding of, or a natural affinity with the Lord. Understanding this, when David speaks of the Lord, we would do well to listen carefully.

Our verse here is the final psalm and thus the last recorded verse of scripture brought to us by David. While the entire body of scripture by or about David is interesting, there is always something extra interesting about final words. It seems reasonable to expect the final scripture of David to be an important observation about God and I believe that David comes through for us powerfully here.

Like many biblical final words, David’s were words of encouragement. Encouragement to praise and worship the Lord. Perhaps this is surprising to some. After all, David wrote often of the attributes of the Lord. He wrote about his love and his mercy and his protection. He wrote about his majesty and even prophesied of his crucifixion. These are all weighty matters that would have been worthy of being David’s final words. Instead, David reverts to type and his worshippers heart rises up and he tells us that the most important thing we can do is praise the Lord.

David leaves no wriggle-room for those looking to avoid this responsibility. He qualifies his directive by including all who have breath. That’s a solidly inclusive call to action. If you’re breathing, you should be praising the Lord. Because, according to David, that’s the most important thing for us to do. And a great way to round out the book whose name, in Hebrew, means “praises”.

Chappell’s Fifth Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

After quarter of a century of tinkering with computers and 15 years of programming them to earn my living, I would have to say that some observations are so obvious that I almost feel it’s redundant to speak them. This law would certainly fall within that realm. But, repeated observation of real life in the I.S. industry, on both sides of the Atlantic, has given me cause to believe it necessary to share it.

Simple is good.

As a rule of thumb, when considering designs or development approaches, always err on the side of simplicity whenever possible. Naturally, there are a few things in this life that are blisteringly complicated, but unless you really are a rocket scientist, it’s unlikely that what you do is one of them.

I have seen far too many designs ruined for the lack of simplicity. I have witnessed far too much code that spends more time trying to be clever rather than getting the job done. This law pretty much goes hand in hand with my second law of programming. In order to write code that you can read at 2 a.m. you need to write in a straight-forward fashion. To be able to write straight-forward code, you need a simple design. You need a design that solves the problem at hand and doesn’t play the “how many patterns can I squeeze in one UML diagram” game.

Simplicity also has the added benefit of producing systems that work better and are ready sooner. Simpler systems have less components, less relationships between the components to manage and a much lower chance of adverse behaviour between components. If programmers produced physical items, we’d describe them as streamlined and with less moving parts!

Learning Projects

When learning a new programming language, and I’ve done this more than once, there are certain steps that I typically take in the process. I like to poke around the language web site and then read the getting started tutorials. If I like what I see and it fits my definition of an esoteric programming language, I’ll install it and try my hand at some examples from the tutorials and the classic hello, world program.

These steps seem to be fairly normal for geeks like me and certainly the writing of a hello, world program is enshrined in programming lore and tradition. What is less clear is the recommended path to take after that. Some people complete tutorials, others buy books and work through them and then some dive in and work on a project so they can learn as they go. None of these are bad approaches, but I think that there needs to be something between working through tutorials or books and the big project for learning.

To this end, may I suggest the concept of Learning Projects? This involves writing a series of programs of increasing complexity that incrementally explore the capabilities of the language. I’m looking at replicating a select number of the traditional Unix tools, starting with the simpler ones and expanding from there.

In some ways this is an expanded view of the concept of Learning Tests. Learning tests are tests written by a programmer learning a specific language to help them understand the language they are learning. (I don’t know who first coined the term, but I first heard it from Mike Clark.) There is nothing wrong with learning tests, but when approaching a wide number of languages, not all will have testing frameworks available and, most importantly in my view, the end result is not anything you can use or recycle components of after the learning effort.

Each of the programs in the Learning Projects are sequenced so that the programmer is learning at least one new capability of the language. These capabilities include writing to the standard output, return values, file handling, calculations, directory operations and system calls.

Now, allow me to present my suggested list of Learning Projects:

  • Hello World – This ensures that you can compile and run a program in the language and get standard output somewhere that you can find it.
  • true & false – Ensures that you can pass return values to the operating system.
  • echo – Requires you to process command-line arguments.
  • cat – Requires you to be able to read files and standard input.
  • wc – This requires handling multiple files, loops and arithmetic.
  • touch – Requires you to be able to create a file or update its timestamp.
  • cp – Ensures that you can read from and then write to files.
  • head & tail – Shows the ability to selectively read lines from files.
  • grep – Apply regular expressions to file contents.
  • strings – Shows the ability to selective read bytes from files.
  • od – Read from a file and apply fancy output formatting.
  • rm & rmdir – Be able to delete files and apply recursive deletion.
  • find – Recursive directory descent.

I believe that by the time a programmer has worked their way through this list of Learning Projects, they will be ready and well prepared to take on an interesting project for the purpose of more fully learning their programming language of choice.

Chappell’s Fourth Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

Software quality, that marvelous thing that every programmer seeks for, as I explain in my third law of programming is all about caring. The only problem is that while “quality is caring”, there have to be actions that this caring drives you to. The first and most important of these actions is unit testing.

Unit testing is the first tollbooth on the road to software quality.

I like to describe unit testing as a toll booth because there is a price to pay for quality. This price is typically non-monetary, but nevertheless very real. The analogy of a road seems to fit software quality very well. Software quality is not a one time thing, it is a journey to a destination. The toll booths on the road to software quality are the price that we must pay, the efforts that we must make, to complete that journey.

Journeys have three phases, the beginning, the travelling and the arriving. Unit testing is the beginning, the price of admission, that first tollbooth which permits you to drive on the road. With toll roads there is no free travel. You pay the toll to get on the road, you pay regularly as you travel along the road and then you pay again to exit the road.

There is no free lunch, or TANSTAAFL as the Perl guys like to say. If you want to do anything well, it’s going to cost you time, effort, money or all three. Software quality follows this fundamental law of life.

Chappell’s Third Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

During a conversation the other day with a friend of mine (name withheld to protect the innocent) the subject of software quality came up. My friend was very concerned that raising software quality would be an expensive endeavor. They were quite surprised when I told them that quality does not have to be expensive and that it can be close to free.

“How is this?” you ask. Simple, the truth is that:

Quality is caring.

Software quality is like security, you have to build it in from the initial design. Retrofitting is not an option. The way that you build quality into a system is by caring from day one.

When you care, you consider matters more deeply. Your requirements gathering will be a little more careful. Your system design will be a little more thought through and better researched. Your code will be cleaner. Your testing will be more consistent. Your release process will be followed closely. Everything will be better.

There are some things that you cannot measure objectively and there are many aspects of quality that are subjective. This does not mean that they aren’t important and it certainly does not mean that your customers won’t notice. Quality is something that shines through and is visible, even when it’s not measurable. Delivering a quality system shows that you care, because quality is caring.

Chappell’s Second Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

With all of the benefits of modern computer science research, I find that many programmers still omit one basic thing from their programs. No, I’m not talking about patterns, or POJO’s or any of the other trendy buzzwords that a modern programmer is expected to be knowledgeable of, rather I’m talking about something more basic than that.

I’m talking here about the ability to:

Write code that you can read at 2 a.m.

As any programmer that has taken a support call in the middle of the night will tell you, supporting other people’s code is the worst. At least with your own programs you know why you wrote them and what they’re supposed to be doing, but with someone else’s, you usually don’t have that luxury.

This will usually result in frantically looking at any available code for the program to see if it offers any clues about it’s purpose for existence. Naturally, this is where you discover that the author had the bizarre habit of using single letter variable names for everything and you can’t understand a thing. And not a comment in sight, of course.

The answer, of course, is to assume that someone might need to understand your code in a hurry and that you should write it clearly and concisely, so that it can be read even at 2 a.m. by someone in a frantic hurry, that is still trying to rub all the sleep out of their eyes and who is unlikely to have a copy of the specification around to read.

Chappell’s First Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

There have been many fine developments in the art of computer programming in the last few years. I especially appreciate “Test Driven Development” (I consider myself fully test-infected) and automated build processes using tools like ant or Maven. And there is still more to come, be it Aspects, grid computing, or lightweight web frameworks like Struts. This is all very good and I welcome it.

But there does not appear to be any great appreciation of, what is one of the fundamental “laws” of computer programming:

Working code trumps everything.

This is a basic truth, at the same level as “1 AND 1 = 1″. Learn it, live it, there will be a test.

As a computer programmer (24 years under the belt, 14 with salary), I love to write code and I love to re-write old junky code, but I have learned that there is enough work to go around, without the gratuitous re-writing of old code. If it works, and usually it does, if we can be honest with ourselves, then we should leave it well enough alone.

I realise that this is close to the old adage about “don’t fix what isn’t broken”, yet I feel that it’s sufficiently different to deserve specifying individually. I’m not saying that we should ignore bad or faulty code, just because it mostly works. Any measurable error rate in code means that it doesn’t work to my satisfaction. I’m talking mostly about legacy code, typically written in COBOL and running on a mainframe. We younger bucks (less than 28 hex thank you) tend to look at older systems and insist that they should be re-written in <insert name of trendy programming language here>. This is the time to remember that working code trumps everything. I don’t care how buzzword compliant your latest language is, if I have working, proven code running, then I say leave it alone and figure out new and interesting ways to interface to it if you have to or just get on with writing some of the boatload of other systems that people are asking us for.

Diary Of A Great Week

The past week has been fun and satisfying. There were a few challenges, but the end result was good, so let’s celebrate by recapping the good things with a selection of photographs.

Watching the Madison fireworks

Watching the Madison fireworks

A beautiful rainbow seen from our front porch

A beautiful rainbow seen from our front porch

Peter's first visit to the Shawano Perkins

Peter’s first visit to the Shawano Perkins

Part of the Princess Posse at Family Camp

Part of the Princess Posse at Family Camp

The view across the lake at Shawano

The view across the lake at Shawano

With my lovely bride by Shawano Lake

With my lovely bride by Shawano Lake

We stopped for Ice-cream while traveling around Shawano Lake

We stopped for Ice-cream while travelling around Shawano Lake

Peter riding a pig

Peter riding a pig

More of the Princess Posse

More of the Princess Posse

Peter enjoying a deep theological discussion with my pastor

Peter enjoying a deep theological discussion with my pastor

Visiting with extended family on the 4th of July

Visiting with extended family on the 4th of July

Sorry for the poor photo quality. I need to take my big camera with me more often, but even mobile phone pictures are better than no pictures, so please forgive me.