department zed | ramblings from the great white north

There are a lot of times when I’m talking to others in the software development industry when I realize how lucky and unique I am; those who know me real well know that this software dev thing was not what I was trained to do.  For those of you who don’t know me, I hold a Ph.D. in music composition; I was trained in all sorts of experimental composition techniques, an expert in computer-based music, and pretty good at most music theory (including Schenkerian analysis and set theory as applied to post-WWII music).  I put myself through a B.A. and an M.A. without taking out any student loans by working full time as a ASE-certified mechanic for Sears (of all places!); in the past few years, I’ve done more than my fair share of both home repair/building and furniture design and repair.  To top it off, I’ve been lucky enough to, in the course of 10 years of software development, do a lot of work for a wide variety of industries–all of which have been great learning experiences.  I can tell you about the problems of water distribution for heating and cooling a major city, the ins and outs of food distribution and category management, the inside scoop on what makes trade show exhibits work, the absolutely stunning profit margins one can make selling cosmetics, what it’s like to work on supporting a pure brand (see No Logo), the kind of internal politics that govern the assembly and release of major software products, and more.  To top it off, I do my best to maintain a working knowledge of things such as architecture (buildings and what not), civil engineering and city planning, politics and the implementation of ideology, certain social issues introduced to me by people I’ve loved, education and new techniques of pedagogy, and more.  I mention these things because I find (among other things) that this breadth of experience has led me to a lot of different approaches to software development than most.

One in particular that stands out in my mind has to do with laziness.  You see, all developers are lazy.  It’s the nature of the discipline; we are employed to write software that will automate tasks.  A solid majority of the time we automate these tasks because we’re lazy and we don’t want to do it ourselves.  Since all we do is figure out how to make a computer do these things for us, it’s only natural that we will try to write more software to do more for us.
What I find ironic about this is that more often than not, a good software developer will spend a ridiculous amount of time trying to automate a task so that they don’t have to do it themselves.  I’ve known fellow developers to put in 18 to 20 hour days for an extended period of time–just so that in the future, they don’t have to do some particular task.

Oh, delicious irony.

Something else that I always seem to find amusing is the sheer ingenuity that can be applied to being lazy.  There have been some really brilliant things created simply because some guy was sick of having to deal with a manual process.  Data Transformation Services (part of SQL Server) is a great example of this; it is an automation tool to run database scripts.  Ant is another one.  Many languages we use today (Perl immediately comes to mind) were designed for this exact (well, maybe not exact) reason.

However, we should never lose sight of the idea that sometimes you really just need to buckle down and do things the old fashioned way.

The one shining example I can think of off the top of my head is documentation.  No one wants to write it (we’re lazy, remember?).  The immediate solution many come up with is to somehow automate documentation in a way that is least painful; the usual solution is either Javadoc or something based on the same concept, where documentation is embedded within code, and a tool is made that will parse it out and assemble it into some sort of usable package.

I don’t know about you guys, but the only thing I’ve ever found Javadoc-based help useful for is to see all of the fields of a set of objects, with method signatures.  After that, it tends to be useless–because that kind of tool never gives a real good idea of what the overall architecture of a particular code base is.   Unless, of course, you write a lot of documentation in code–at which point you’re doing what you should have done in the first place.

Write the damn docs in a real document.

I learned this through, of all things, woodworking.  There’s no getting around certain tasks in woodworking, and it can require a lot of patience.  To give a simple example, to properly varnish a piece of furniture, you need to apply at least 3 - 4 coats of good varnish, with a full dry cycle between each coat–and a good sanding with a very fine grit sandpaper after each coat is dried.  Before you get to that point, you have to sand and scrape (using a scraper that looks like a straight razor with handles on both ends).  If you don’t do these things–and you don’t learn the patience to do them right–you end up with a piece of furniture that has surface imperfections embedded in a slightly cloudy polish.

If you asked a software developer to do that, I think it would go something like this:

1. Do it the first time, and skip over a lot of the more important parts (like the initial scrape and a real sanding between coats)
2. Do it the second time, and this time give a little more time between coats, and a little more effort.
3. Start to do it a third time, and decide that instead of learning the patience you need to do it right, you’ll try to invent a machine that will be patient for you.

All of which to say is that while it’s a good thing to have a hacker mentality, it’s a better thing to recognize that sometimes you just need to be a little less lazy about something, and a little more patient.  In the end, sometimes we all need to step back and recognize that it’s not always the best thing to create new tools–that there’s nothing wrong with using some of the tools we already have, and simply using elbow grease to “get ‘r dun”.

(Also which to say that a lot of my fellow developers should think sometimes about studying things that have absolutely nothing to do with computers and coding.  Go smell the roses and bask in the sunshine once in a while )