Making it work takes a little longer;
Making it work takes a little time;
Making it work takes a little longer;
Making it work takes a little time...
Doug & the Slugs, 1982
--------------
Recently, we switched the cable, internet and phone provider for our house. I am a little embarrassed to say that the process created a surprising amount of stress in my life. (Must be a pretty nice life, right?)
It got me thinking about a few things.
I started my career as a programmer years and years ago. In High School, I first learned about computing using punch cards. In University, it was languages like COBOL and Fortran and JCL. During my co-op work terms, I was programming chips, writing command-line processors, and even tinkering with machine-level techniques (writing Assembly language code, re-routing system interrupts...) to make DOS do crazy tricks.
It took a long time and a lot of effort to make those "early" computers do what you might believe to be laughably simple today. And when one encountered a bug, it could be days and even weeks of digging through bytes and bytes of dumped data to find the problem.
Eventually, it was always possible to find a solution. Sometimes, you didn't know why the solution worked, but it did and you would carefully document what you had done, cross your fingers that the fix (or workaround) would keep working, and move on.
Then all that machine-level stuff - having become relatively stable - would be neatly encased within higher-level languages, function calls, APIs, objects (etc.) so that no-one would ever have to re-write it and things would keep working. The low-level stuff became a construct we could count on.
And of course, that's the legacy inherited by everything that relies on computing today. Including the cable and internet in my house: Constructs within constructs that tend to work.
In the course of switching my house over from one cable/internet/phone provider to the other, some of the stuff that was working stopped working: My television could no longer connect to the internet so that I could use it to watch Netflix; My phone stopped being able to tell me when somebody left a message on it; TV shows would intermittently freeze for no reason; Network passwords changed and kept getting lost; My beloved TV channels were all over the place without any meaningful connection to where they used to be; And so on.
To get on top of it, I had to fix a bunch of micro things that I hadn't had to touch since the original provider had installed their equipment. My constructs were under siege!
Observation #1: When stuff you count on stops working, even minor stuff, it is very very stressful. And when you change what's working, or change is thrust upon you, it inevitably stops working for a while (or it at least stops working the way it used to). It is far easier not to change, even if the end-state will leave you better than you were.
Extrapolation #1: When change isn't a choice, the stress is worse.
Now in the case of my provider switch, MAKING IT WORK took a bit longer, took a bit of time...but a few weeks later, everything had pretty much reverted to normalcy...except some TV channels were still occasionally freezing.
We called in the technician.
The technician wasn't an idiot. He seemed like a nice and very intelligent guy. His training told him that when some TV channels freeze, try switching the cable box for another one. If that doesn't work, try switching the modem for another one. If that doesn't work, try switching the cables themselves, and the cable connectors. If that doesn't work, try switching the cable box again. And again. And again.
The technician sat in front of my family room TV for 4.5 hours working his way through 7 cable boxes (the first 3 were refurbished and the next 4 were brand new). He never once opened a cable box to see if something was wrong inside. He didn't tinker with any code. He didn't call another technician. The cable box was a construct for him. It worked or it didn't work. If it didn't work, it was broken.
I remember a few years ago one of the PC manufacturers started "fixing" your laptop's problems by sending you a new one. Presumably, that was a far easier, far less expensive solution than trying to actually find out why something was going wrong. We all lauded the manufacturer for their amazing customer service.
Other technology companies started doing the same thing, and today I'm guessing most of them do. I think, for example, that smart phone manufacturers will give you a new phone when something goes wrong with your old one rather than trying to fix the old one (if it's still under warranty, that is). Clearly, the cable/internet/phone providers have embraced the same service model.
Great when it works. Frustrating and pretty silly when it doesn't.
At around 11:00 pm, I put on my programmer hat and engaged the technician in a brief dialog about what else might be going on (beyond an amazing streak of broken cable boxes). Within 5 minutes we had hypothesized that maybe my TV's Netflix-enabling internet connection was conflicting with the cable box's internet connection. Within 10 minutes we had proven that to be the case and had found a work-around (connect the cable box first, then connect the TV). It may keep working. It may stop working again. The technician and I are both crossing our fingers.
Observation #2: We come to rely on our constructs. When they stop working, we don't particularly feel like expending the effort to look inside and find out what's wrong. Sometimes, it doesn't even occur to us to do so.
Extrapolation #2: Change sometimes puts our constructs in jeopardy. Making them work again might take a little time and effort, including looking inside, but it is entirely possible.
So now, if you're still with me, I have a few questions for you:
- What change in your life is currently undermining one or more of your carefully protected constructs? Are you recognizing the stress that change is creating for you, understanding where it's coming from, and accepting that the stress is perfectly okay?
- If you are stressing about a change, are you able to identify what constructs might be under siege? Can you see them for what they are (carefully created layers of solutions upon solutions that you stopped challenging long ago) and somehow muster the energy to look inside them to see what's no longer working?
- Are you willing to invest the time and effort to make it all work again?
And that, dear friends, is my attempt at a little wisdom on this cold and miserable morning.