I really really fucking love my job. I love my boss... I love the work I do. I got budget approval for $13k worth of improvements and upgrades to my database, largely because my boss recognizes the tool it is and wants to expand it's use throughout the agency.
The man who hired me resigned- he's going to work for the Make a Wish foundation (good for him!) and offered me a job on the way out the door. Very flattering, but I love love love my boss and I wouldn't consider leaving her for him under any circumstance.
The pay is HORRIBLE (think just out of college type money- really really bad money) but the work is meaningful, appreciated and shit, it's FUN!
Cup -o- Duncan Donuts coffee this morning, in a desparate attempt to jolt myself awake. I'm feeling the hum.
My office is driving me to drink.
Gee, I'm on prozac to deal with the nuts. I have one mug of coffee per day. For a wake-up, try boiling coffee, then strain the grounds out for army/kannchen jolt. Kinda turkish style with espresso grind, and 16 oz mug. Pour it on a grave sometime. Zombiecoffee wakes the dead.
coffee, coffee, cooooooooooooooooooooooooffffffffffffffffffffffffffffffffffeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!
We're still dealing with our problem customer.
At this point, we're finally getting them to tell us specific bits of information that allows us to prove that we're not at fault for much of the problems they're experiencing. It's like pulling teeth, but we're making a pretty good case.
Still, I'm amazed by the brazen stupidity and arrogance of one of their vendors. This vendor is convinced that we are the problem, despite plenty of evidence to the contrary.
They provide a stream of XML data via TCP/IP. We connect to this stream to watch for a playlist.
Occasionally, this stream cuts out, and we reconnect. "Co-incidentally", this happens at about the time we run out of playlist information for this one channel. It also happens at about the time this other device that has nothing to do with us, but also depends upon this XML stream, starts to show problems.
Amusingly, this stream provides two channels of information. We reconnect quickly enough that we get the other channel's playlist information without issue. But, "peculiarly", we don't get playlist information for this other channel when it happens.
Now, given the facts, I would assume that something from the other channel is causing the XML stream to die, then recover (for people to connect again), but never actually get the playlist information out for that channel.
However, the arrogant pricks at OmniBus (a British company, if that means anything to anyone) refuse to believe this is their problem. Oh, and they are having a difficult time figuring out how to evaluate what information is coming from the XML stream.
So, since they're too stupid and arrogant to do this themselves, I've got Putty looking at the output and logging the stream to a hard-drive. When it fails, the putty connection will die, and we'll see the last thing that they sent us.
I have a ticket open that's been bandied about for over a month now, but just yesterday the client STARTED USING ALL CAPITAL LETTERS TO EMPHASIZE THEIR POINT.
I didn't take that too well, and they fell just short of calling me stupid, which never goes over well with me.
Turns out the problem is that they're comparing data from 5/7/2010 to data from today or yesterday, and as it turns out the data is DIFFERENT! And they insist on knowing why our system is broken because it's giving two differetn answers for the same question, when one question was asked on 5/7/2010 and the same question asked today.
Makes me very angry.
When PuTTy failed, we sent the tail end of the resulting log to the other vendor, with a very carefully crafted e-mail explaining what it is, and suggesting how they could use it (all without actually calling them morons, which is what made the e-mail difficult to write).
They didn't respond arrogantly for the first time since we got drawn into this nonsense. His response was still kind of clueless, but something along the lines of actually trying to research a problem. Their normal reaction is to constantly do 'damage control' and avoid taking the blame for anything... even when it's blatantly their fault.
problem.
Of course that doesn't mean it's okay to blame you, but if you were stuck between a rock and a hard place, you'd be stressed out too and in an attempt to find somebody to help you might start yelling instead.
I've seen people do that to me.
I'm a developer, I happen to know a tiny little about networking, but I'm not a network guy, but I can tell if my program is suffering from network problems.
But I try and point out to networks that something is dropping my TCP connections on me please make it stop, and they don't have the tools to enable them to find the problem.
Bad situation, but it happens.
Our initial response to a reported problem is to 'look into it'. And we do. We can usually narrow down the problem fairly quickly... and fortunately, it's usually something dumb that someone did. But we always consider it possible that our software has had some kind of problem.
However, when the software hasn't displayed the kind of problem they're seeing for several years, and we're damned familiar with the kinds of things that can cause said problem, it's frustrating that people won't believe us.
Worse yet, when the vendor causing our problem says things like, "It can't be us, it's not in our bug tracking system," when we've been reporting the problem for literally years, we start to understand why their bug tracking system is perhaps always empty.
Of course that doesn't mean it's okay to blame you, but if you were
stuck between a rock and a hard place, you'd be stressed out too and in
an attempt to find somebody to help you might start yelling instead.
My problem is that I usually can't keep my mouth shut. I have a habit of calling it like I see it. This gets me in trouble sometimes. I also don't lie well, which can be a problem because lying is a skill often required in business.
Oh, yeah, the current reason why they are not looking into it for our mutual customer is because they're busy working on something for FOX.
That's hilarious.
I wish *I* could get away with that.
"Oh, hang on, I need to work on something for this other customer for a while. Never mind that it's a near-complete disaster right now for you, and you're about to lose your own customer over this, FOX is more important than you."