This morning I spent an hour or so installing a new wireless router to replace the wired router we have been using since February 2000. The process seemed simple on the surface; unplug the CAT-5 cords and power supply from the old router and drop the new one into place. Access the build in web accessible configuration and we’re surfing the Internet wirelessly.
In the actual doing of these steps I made two minor, easily correctable mistakes. Either of these taken individually would have been easy to diagnose and correct. Taken in tandem they proved to be difficult to overcome. In the end I was forced to contact my broadband provider to sort out what had happened.
In the process of installing the new router I was presented with a choice. When my connection didn’t work after making what I thought was the correct selection I should have backed up and tried the other option. Instead I decided that I must have another “problem.”
In my efforts to correct this nebulous other problem I introduced the second error. When I called for assistance the technician quickly zeroed on the incorrect choice as my problem. Once I made the correct choice every thing would work he assured me. Only, because I had wandered off the reservation earlier, it didn’t. It only took him a few minutes to locate my gaffe and correct it.
The thing I find interesting in all this is the whole paired problem paradigm. I often see situations in my employment as a programmer where outwardly it appears as if there is one problem. But upon examination you discover there are really two problems (or three), one behind the other causing the situation. I think that in life we have paired problems as well. Only without the concrete (if somewhat obscure) error messages and indicators that software gives us, life’s paired problems are much tougher to identify and correct.
In the interaction that occurs between a software developer and their code there are lots of cues as to the understanding of the problem domain by each side. The development tools provide feedback to the developers commands and from that feedback the developer (hopefully) knows what to do next.
In real life, interactions don’t happen via some magical interface that provides cues and hints as to the other participant’s understanding. You may think you are communicating clearly when in fact you aren’t. We have to develop our listening and intuitive skills to provide us with feedback about our interactions with others. We need to have a safe place to develop these skills, a place where we can stop the other person and say, “Is this what you really mean?”, or “I’m hearing this, is that what you are saying?” If we never develop our ability to debug our own life, we’ll spend most of our time being frustrated and angry.
I am fortunate to have a loving and very safe relationship with my wife. I have a place to develop my human interaction debugging skills. Within the safety of our relationship I have learned to trust my instincts and intuitions so that when I am out in the world I can believe what I am telling myself.
Without a safe place to develop these skills I would be suffering from masked problems on a daily basis; life would be much harder and more difficult. I’ve learned through hard experience to call for help when I get in over my head technically. (And to call earlier rather than later…) I’m also learning to actively look for feedback from my trusted companion.