Simple Pleasures Are the Best

Years ago, when my dad was in his seventies, I tried to teach him how to use a computer.  He was overwhelmed by what was for him a serious challenge.  This was long-enough ago that there were still dedicated "word processors," units which looked like a computer keyboard and monitor, but which had only one function — to create documents.  Learning how to use them was far easier than learning to use a computer and all it's distracting features, even in those days when they operated in a relatively limited field of effort.

My father tried, but a word processor was not for him.

I realized that the only technology my father might appreciate, even master, would be the closest technology to the manual typewriter he'd been using his entire adult life, a machine which would mimic his old Royal's features.  I was happy to show him how to work an electric typewriter, and he took to it like a fish to water.

I believe that one should consider before racing to adopt the latest technology, particularly if you are efficient using the technology you're used to using.  You should account for the expense, time to adjust, retrain, and even the loss of some aspect of your current process that you might come to wish you had retained, for whatever reason.

I posted about whether or not to agree to software updates years ago.

Be at ease with your own expert notion of what's comfortable for you.

Always use the simplest effective technology.

The Best Prescription

It may be better for your own mental health to ascribe human qualities to your computer’s performance.  For example, saying, “My computer’s in a funk today, not getting much done,” suggests that you should just be patient, perhaps try tomorrow when the machine’s feeling better.  While on the other hand, treating your computer’s performance as a technical issue—which of course it is—may have you spend the rest of your day trying to solve a problem which might just go away on its own after the computer has had a good night’s sleep—technically, a reboot.

If It's Fixed, Do We Care What Went Wrong?

Today my scanner would not respond, saying another program had the scanner in use, reporting this to me in an error message.  I closed every program I thought might use the scanner, no change.  The error message still maintained that the scanner was in use, and advised I reboot my computer.  It occurred to me I might just reboot the scanner, and when I did, the error went away and I was once again able to use it.

This is an example of countless times we know how to make a problem go away without actually knowing what the problem is.  I often think that most computer problems have very specific causes, like the old cartoon about the mainframe dying every night at a particular hour, confounding technicians, simply because the cleaning lady unplugs it to plug in the vacuum.

It seems likely to me that my scanner was not in use at all, but that some data bit had tripped to give the appearance that it was.  Some technicians delight in tracing such errors down, and are often paid handsomely for their efforts.  Still I wonder why application code doesn’t report errors more reliably and with greater accuracy.

In the old days, technicians poured over “stack overflow” reports which left a trail of… well, everything a computer was experiencing at the time of a system crash.  No one has time for that anymore, so we rely more heavily on error messages to tell us what went wrong.

I feel there’s a lot of room for improvement in error messaging, and it might be interesting to actually know what’s happening when things go wrong.  

Of course, our software applications and operating systems are vastly more complicated than they once were.  Perhaps there’s no time to test every conceivable interruption, and to neatly alert us what’s wrong.  But if each step in a software program verified what it was doing, in theory, when it was not able to perform that step, it could throw report an error that would state clearly what it was unable to do.  It might even suggest the cause of its problem, identify a key antecedent to it’s action, or other programs that were interfering with its operation.

Persons more interested in all this have addressed everything I just mentioned.  But I sense that error reporting — and recovery from error — could be much more robust than it is.  

Perhaps the reason error recovery isn't more robust is that it’s just easier to restart the program.

Nothing Is a Closed System

I find the intentions of "open systems" compared to "closed systems" fascinating.  Proprietary Apple is airtight compared to Windows which is locked-down compared to free-ranging Linux and others.  I was recently struck by an article by acting coach Anthony Meindl.  It made me think of computer code from a fresh angle:

If you look at your life, the tremendous amount of effort you had to exert to overcome obstacles and get to where you are today speaks of the possibility of your spirit. But it also shows that nothing is a closed system. Nothing. To think otherwise is to limit something that is limitless. That is—you.

Next time we run up against the limits of proprietary code, we might appreciate our strengths, and leverage our creativity to triumph over closed-mindedness.  Not encouraging hacking here, just resourcefulness.

Six Months to Live

I recently completed a short stint as an IT Technical Recruiter—short, because I didn't make any placements, and particularly because the owner of the recruiting firm I associated myself with and I mutually agreed I wasn't a "good fit."

My most valuable take-away from this experience is the fact that, if you’re an IT pro who finds him-or-herself unemployed for any reason, after six months your career is simply no longer viable.

I've been out of an IT job for far longer than six months. I had no idea my professional life was over. When I learned that it was, I felt how I imagine a zombie must feel when he first notices his accustomed lifestyle evading him.

I have a major IT home project I’d like to finish before I die—as in real death—which involves making one large searchable database out of my two enormous and very distinct existing ones. Perhaps only so my descendents can reconstruct some of the essence of me after I’m gone. This project will ensure me a life in IT while my ruined career remains among the walking dead.

And ensures my digital existence when my real existence ceases to… exist.

When to Upgrade Software, Hardware—or Anything Else

It's reasonable to have to pay for upgrades, but you should only upgrade if you require the functionality the upgrade provides.

The only reason to upgrade when you don’t require upgraded functionality is because the current version will no longer be supported. If you upgrade in this case, you aren’t actually upgrading, you’re meeting a support requirement.

Upgrades which increase performance, or correct errors or design flaws, should be called fixes.

It's not reasonable to have to pay for fixes.