Why did I choose to call this blog "Notes from a dark corner"?
I work in an office where if you stop moving for long enough the lights go off. My job involves trying to figure out why software is not working as expected. Quite often this is not particularly obvious so I often find myself in the dark both literally and metaphorically. I did buy myself a USB based infrared transmitter (that even came with a .NET based SDK!) in the hope of solving the problem (my lights can be controlled with an IR remote) but then I found the lights used a different protocol to the one supported by the transmitter. I guess I could have spent hours or days trying to figure out the protocol, buy a new transmitter or try to rewire the old one. But life may be short so I decided to move more often. It's almost certainly better for me! In my job this is what we now refer to as a preferred solution.
I work for Microsoft in the UK. My job title is "Escalation Engineer". I'm not sure whether that means anything to people outside of Microsoft or not. One of the risks of working at one company for too long (I've been here for 10 years) is that your mind becomes infused with a load of jargon and acronyms that nobody other than your colleagues would understand. Mind you, I was in a meeting at a customer's office the other day and noticed at one point that they seemed to be speaking a language all of their own. So I guess it's true wherever you work. What does an Escalation Engineer do exactly? Well, I work within Microsoft's support organisation and I specialise in solving problems that are technically hard or politically messy. Or urgent. Or critical. I think you get the idea.
Ten years ago when I joined Microsoft I supported Visual Basic 3 and our customers were mostly writing 16-bit client applications that maybe spoke ODBC to a database if they were sophisticated. Our work was mostly phone based and the commonest question was "Where is OLE2UI.DLL?". (The answer to this, in case you are interested, was "Don't worry it doesn't exist. Just edit this INI file sir and the error message will go away."). To get information to a customer we cut and pasted a KB article into a Word document, printed it off and then walked over and fed it into the fax machine. That was of course until Mike Hall wrote his skunk tool (I think it was called FaxMan or something) that allowed us to to do it from our desks. If a customer needed a software update we used to order it in another tool (called Spidrs or something) and Jim in the post room got a message to send it out.on a floppy disk If a customer wanted access to the knowledge base he or she could dial into our bulletin board and download a ZIP file of all the articles they were interested in.
Ah, how things have changed!
Now most of the customers I assist are developing large, scalable web server based systems. More often than not these systems are business critical, performance is crucial and reliability is an abolute must. Almost everything we might need can be sent or downloaded over the net, we can use Live Meeting to connect remotely to systems if desired and search engines give us all knowledge at our finger tips. So is software support any easier now? In some ways it is but the problems have got a whole lot harder. But with that they've got a lot more interesting and that is why I am still here to write this blog ...