Today was one of those busy days. Despite dozens of interruptions I was able to get a bunch of real work done, even if it wasn’t quite everything I had planned on doing.
I started out in the morning as I do nearly every Monday morning, wondering, wandering around my mind, wanting an answer to that persistent morning after the weekend question. What the hell was I working on last week? It always takes me at least few minutes before the caffeine caffeine sets in.
I of course know what I was working on last week, but the details elude me. Even after reviewing my careful notes (on a set of 5×7cm recipe cards), I have to let it sink in to uncover the memories obscured in the context swtiches a weekend imposes.
After unearthing my memories, I set off on my first task: to find some documentation for a piece of hardware that arrived in the mail for the second time last week. The second time! The first time the hardware arrived I was stupid enough to leave the envelope it was in within the sacred proximity of the garbage can. Somehow, in their finite wisdom, the cleaners mistook the not-in-my-garbage-can 50×75cm bubble wrap envelope as garbage. I’m not sure why they shipped a CF card in a 50cm envelope, but the wisdom of the gods of shipping (and of office cleaning) eludes us all.
As with most simple pieces of development, the details are full of questions. I install the new hardware, read the documenation (well, skimmed it), and run the test tools. The hardware works, and I think that I understand the problem. Now how to we make this work in our product?
It’s easy to find answers to the simple part of the question. I find enough examples to figure out the easy bits, which leaves me with the details. The nasty details. So what is the information going to look like from this thing? How big is it? Does the customer know what they’re going to do with the data? Of course the customer hasn’t really thought about the problem either, so I go and find someone in sales.
Our sales department puts me on a conference call with our customer, who is really a sales person for another customer. Great, an elbow. There’s no traction when dealing with an elbow, as they don’t really know anything about the problem. They just bend around it, keeping you a safe distance from the answers while trying to convince you that they actually know something. They can only connect me to someone who has a hope of answering my question, and they promise that a techie will phone me in a few days. Great, I’ll have to wait a few days for a real answer.
The sales person makes it absurdly clear that they haven’t even considered the problem yet, which lets me make most of the decisions for them. I assume that all of my questions have simple answers, and go about framing a tool to prove the point. Most of my afternoon is filled helping another project figure out where it’s going, so I don’t quite have time to finish my prototype. I’ll leave that for tomorrow.
The morning reminds me that there’s this huge gap between sales people and developers. Developers don’t usually grok the real world, as they have to fill their heads with billions of tiny details about hardware, software, and how to make it all sing. The details of technology are petty and pedantic, which leaves a mark on their personalities. Sales people are a contrast, burried in details about who’s buying what, what those people want, and how to get it to them. Developers never have to think about people, while sales people are burried in people.
And I get the best of both worlds: I’m a geek, so I get my dose of the petty and pedantic. I’m also a bridge, I manage developers to help them communicate with sales, customers, and the bosses. It’s a bit of a weird world to live in, like a purgatory where I’m stuck herding cats. But it’s all good, I got to write some software today, and I had time to hack away at some people problems too.