Information really is power when it comes to dealing with technology.

One of the biggest things I have noticed in education in recent years is the rapid embrace of technology.

As the STEM curriculum is embraced in our schools, kids are being introduced to technology at a far deeper level than ever before. This core understanding of technology and complex system design begins to create empathy for the deficiencies they may include. In turn, people with a better technical understanding can feasibly have a better forgiveness for bugs and technical shortcomings.

OK, stay with me here... I’m not talking about campfire Kumbayah and hugging strangers in the streets. I’m talking about the understanding of everyday events, at a deeper-than-surface level.

For instance, if you order a pizza delivery and the driver is a little late, you might become frustrated. However, as someone who spent countless hours in my barely-roadworthy Toyota Corolla on just about every Friday and Saturday night of my teenage years, I empathise with the challenges of their work. Lots of deliveries during peak times mean that sometimes, delays can occur. Perhaps it’s busy traffic, or they forgot the soft drinks... my inside knowledge.

I was reviewing text for this issue of DIYODE when my computer was unexpectedly unable to save my edits to our server. Yes, using a piece of software from giant Adobe, threw me a rather amusing error that looked like an 8yr old had coded it. “Cannot save x for reason y”. Hmmm... we’ve all been there before!

While I was quickly frustrated by the lack of a useful error message, I began to imagine how this came to be. I thought about the hundreds of thousands of lines of code I’ve probably written over many decades, and indeed what is no-doubt many instances in my own code where this type of thing could have occurred.

Without seeing the code behind Adobe’s software (which would likely never happen unless I make a rapid change in careers), I would assume this is a simple switch statement for handling save errors, and the error we have had was not catered for. Something along the lines of:

$error = trySave($file);
$msg = ‘Cannot save $x for reason $y’;
switch ($error) :
    case ‘noFilename’:
      x = ‘file’;
      y = ‘file does not exist’;
    break;
    case ‘noFolder’:
      x = ‘file’;
      y = ‘chosen directory does not exist’;
    break;
    default :
      //add some generic info here so the user doesn’t get a dud message
    break;
endswitch;
  throwError(msg);

Note specifically, the comment under the default case.

Now, there are a trillion different variables around this of course, but many of you should be able to see what train of thought that follows.

It’s basically creating a way to handle different error conditions that a user might encounter, and parsing the relevant information into a generic statement. The language is valid PHP using alternate syntax, but treat it as pseudocode. Regardless, you should still see the basic idea despite what languages you’re familiar with.

The point here is not that we can try and figure out how an error occurred, but understand that until AI becomes self-replicating, technology is still made by people. They get rushed, they have bad days, or they have to pick up the kids from school. The developer likely just overlooked this default error catch. Testing may not have replicated an uncaught exception before it was deployed to the world, and the update was shipped. Perhaps we’re the first to encounter this specific error case! Who knows...

OBSERVATIONS OF MAINSTREAM TECHNOLOGY

While we don’t all suddenly start seeing the matrix when our favourite iPhone app crashes, visualising what’s happened at a code level, it does trigger ideas of what's going on inside.

Just last week, my Apple News app would crash every time I tried to read a full article from the summary. Tap, crash. Tap, crash. Restart the phone. Tap, crash. Hmmm!

Frustrating sure, yet still, within a few seconds, I had visualised a half-dozen scenarios that could cause the error. Perhaps the news site I was trying to retrieve the article from was throwing an obscure error. Possibly a DNS server was down somewhere. Maybe the full article’s link moved recently and things hadn’t updated. The list goes on...

Naturally, the next morning everything miraculously worked fine.

THE UNDERLYING POINT

I promised you a point, and here it is...

The more we understand the technology we’re using, the more accommodating we can become. We understand that things aren’t perfect, and indeed any technology we create ourselves will occasionally have a fault we hadn’t accounted for.

It’s possible the DHT sensor stopped working, perhaps the WiFi password changed, maybe our ATmega had an EEPROM read fault... ANYTHING is possible.

While as consumers purchasing retail-ready items we expect a certain level of competency and quality assurance, as engineers and makers, we can understand how things go wrong. While it doesn’t help if your car won’t start in the morning, this “stuff happens” consideration is a key part of ensuring technology doesn’t become an eternal source of frustration in our lives.