Methods Of Work: Hammering With a Shovel

Seriously. It amazes me how often people, especially-but-certainly-not-limited-to software people, fight with their tools. Would you really spend all day framing a house, using a shovel to hammer nails in? Some people, based on my observations, seem to.

This is not just a software thing; it happens all over the place. I’ve watched people fight with remotes, rail at the self-checkout, complain about their phone.

Changing Channels in Hell

Have you ever seen someone pick up a multi-function remote (one which controls say five devices) and just mash the channel change button over and over again, frustration building as the channel steadfastly refuses to change? Because the remote is in TV mode, when it needs to be in Cable Box mode? Or worse, the channel changes from three to four, losing the picture completely. At this point our poor user usually gives up, and leaves complaining about how the remote doesn’t work or the TV must be broken.

What this illustrates is the gap between the designer’s model (you can change the TV channels, the cable box channels, and the DVR channels! Cool!) and the user’s desire (it’s a remote, just change the channel I am watching!). The user knows what the desired outcome is, but does not understand the idiom of the device. The user is hammering with a shovel.

It happens a lot more if your tool is more complex, because the idiom can be so much harder to divine from the surface interface. In many tools there are multiple ways to do things; these multiple approaches may each be useful in certain situations, but to the new or naive user, it just looks confusing.

Software: Idioms or Idiots?

Programming languages are used to build some of the most complex systems ever, due to their open-ended nature. Heck, one of the really seminal computer programs, Conway’s Life, is itself a programming language. Look at Excel; sometimes I think its real function is to provide a wrapper for folks to write VBA programs. (You are fooling yourself if you don’t think Excel is a programming environment, one probably used by more people than all the others put together.)

Ruby on Rails is popular, and made a lot of hay for pushing Convention over Configuration; an effect of which is cutting down on the number of redundant ways you can solve a problem. This means users are forced (willingly) to do things the “Rails Way”, and this cuts down on user frustration, not because it remove choices, but because you can follow established effective use patterns to get something done. Speeds development.

But you can’t just have one way to do everything; it is hard to build interesting systems with a single brick. Eventually, if you want to build interesting solutions you need to have choices, and soon users will be presented with a plethora of options.

You, The User, Must Grok

Suppose you need to learn a new API. Suppose you are moving your kid to a new public school system. Your son is moving up to a new baseball league. Your daughter is encountering algebra for the first time. You acquired a new fancy car stereo. Or a Roku. Or a new cell phone. Or Mother-in-law.

In each of these cases, you are coming into contact with a new system, a system you hope to work with. (If you don’t think your mother-in-law is a complex system, you haven’t been married yet.) Most people try to make the system do what they want, the way they want. The first approach is questionable, the second is a recipe for disaster.

What you really need to do is divine, learn, guess, somehow understand how the designers of the system meant for you to use it. If you understand how it was intended to be used, you’ll find you can get a whole lot more done. Heinlein gave us the word grok, which captures this perfectly. To really use a tool well, you need to understand the designers’ mental model. You need to grok the tool.

Hammer or Shovel?

You could hammer a nail in with a shovel, but it would take a while and you’d look stupid. In the Real World nearly everyone would put the shovel down and pick up a hammer. Yet all the time I see folks resolutely hammering away with their shovels, never taking the time to understand that thing they are holding was actually meant for hole-digging.

I find this insight invaluable in software. I am primarily a server Java guy, and the Java ecosystem is chock full of useful, complex systems. Eclipse is an good example. You can spend a lot time railing about how Eclipse works, or you can figure out the flow Eclipse wants you to use. I mean, you could use Gnu Make for Java builds (and I once saw someone do just that) but it ignores Eclipse’s whole incremental compilation schtick. The Java Logging API is pretty maligned, but someone put thought into it. They clearly had an idea of how you could use it to solve a variety of problems. Knowing that might make its use more tractable. Subversion actually does want you to use branches; they just have a very specific merge model. Figure it out and you’ll stop complaining about merging.

(I can use Emacs in my sleep, and am just short of hopeless with VI. But it is obvious that if I took the time I could build a good mental model of VI, really grok it, and be just as facile with VI as I am with Emacs. But it’s a religious thing now.)

This insight is useful in life too. Figure out the rhythm of you public school system’s bureaucracy and you’ll find your interactions with it will improve dramatically. Get a basic understanding of the goals of the U.S. Tax Code and you’ll be less surprised at your bill come April (or your refund!). And so on.

Figure out how things want to work and you’ll find you get more done with less effort.

And for Pete’s sake, stop hammering with that shovel.

Explore posts in the same categories: Software, Tech

Tags: Design By Gravity, Software Development

You can comment below, or link to this permanent URL from your own site.