A fact is a fact is a fact. But the context in which you interpret a fact is equally important. And when the context changes, the facts can get reorganized significantly, making what was once a major fact into a minor fact, and vice versa.
Six months ago, I was hired for my skills as a programmer by OpenMethods which has a solid reputation in the voice industry. Very quickly I realized that my skills as a programmer (a fact) needed to adapt to a whole new knowledgebase (a context). Beginning by knowing nothing about telephony applications, I have now been immersed in CTI for six months, and although I have learned a lot, I expect it will be another year before I will feel competent.
This is the best way to learn; little rhetoric, much hard experience. I am continually amazed at how intricate telephony really is. In theory very simple, but in practice, there are dozens of exceptions for every rule, and there are quite a few rules. Even though Open Source and the convergence of telephony-everywhere has brought standards-based design to the forefront for at least a decade, it feels to me like CTI is still ‘young’ and therefore all over the map, or all over several maps.
For example, we get weird things happening in our application which seemed to me at first to be bugs, but in fact are codec-related problems happening further up the “call chain.” It’s strange to fix a bug by tweaking a setting on a remote server, rather than tweaking code. Often before when there was a certain kind of problem in my code, it was because I made a logic or protocol mistake. Now it turns out that in addition to coding skills, to be competent in my field, I have to learn dozens of possible configuration options that are enabled or disabled on a remote server which is sending telephony interactions to me. Only after I have eliminated these configuration possibilities can I begin to look at my code.
When do I know what is a bug and what is a configuration setting? That’s the part I’m learning now. So you see, in some cases, facts are dependent upon context.
Ever so slowly, I learn the hard, the right way, how to manage a telephony platform, which seems to be out of scope for a programmer, but in fact is necessary for analytical and troubleshooting skills. This is not easy. No formal training, just lots of help from my colleagues here at OpenMethods, who indeed have earned that solid reputation mentioned earlier.
I’m excited by this challenge. I love this job because I love to learn, and I love being intellectually intimidated. There are few things so sweet as having overcome a complex intellectual challenge, and made a living doing so. Really, that’s the easy part. The hard part is remaining humble once having done so. That’s next year’s work. The facts will remain the same, but the context will change again. As always.
Jared
March 20th, 2009
9:26 am
Good insight! I remember when I was first thrown into the telephony world… besides having to learn tons of TLAs, I also found out that CTI touches upon everything: hardware, software, networking, signaling, etc. Overwhelming at first, but it is quite fascinating, just as you’ve shared with us… Thanks.