I’m getting some coffee in the lunch room . . . no one else is present.
One of my colleagues walks in and says, “Are you talking to yourself, Paul?”
“No, actually I wasn’t saying anything.” Which I wasn’t. “Maybe you’re hearing voices,” I suggest. “And ironically, you were just insinuating that I was nuts.”
Here’s another colleague in the break room, wiping something off the front of her shirt . . .
“I spilled coffee down my shirt,” she explains.
I ask: “How does that compare with just drinking it, as far as a pick-me-up is concerned?”
“Welcome to Starbucks. My name is Sam. Would you like to try an apple [something something]?”
I couldn’t understand what he said. “A what?” I asked.
“An apple chai [something].”
“No.”
“Are you sure?”
“Can you say it one more time? I didn’t get the last part.”
“Apple … chai … infusion.”
“I’ll have a venti iced latte.”
“OK. That’s almost as good.”
The poor guy really had his heart set on serving me an apple chai infusion . . .
We took Lightning to the Huntington Dog Beach this morning . . .
As we were parking the car, my wife asked, “Do they have bathrooms here?”
“They have portables,” I said, pointing them out.
“OK, you guys go ahead and I’ll meet you down at the beach.”
Later, when we got back to the car, I asked, “Where’s my coffee?”
“It’s all gone,” she said.
“It may be all gone now but it wasn’t all gone when I left it here.”
“I had to pee in it.”
“You peed in my coffee cup?”
“I can’t use those portables.”
“Why couldn’t you pee in your own coffee?”
“I had to make a judgment call.”
“Well . . . thanks for not setting it back and letting me drink out of it.”
I walked into Starbucks at 5:30 this morning, ordered a drink . . . the Starbucks guy asked my name and wrote it on the cup, despite the fact that I was the only customer in the store.
Whether that would be considered a training success or failure depends on whether Starbucks trains its people to always ask for the customer’s name, or to use situational judgment.
I was hoping the barista would call my name when the drink was ready so I could do a comical “who, me?” take, but she just set it on the counter . . .
The girl at Fantastic Sam’s cut my hair too short. She was telling me about a car accident she had yesterday and I asked her, “Were you drunk at the time?”
“In the morning?!” she yelled. “Hel-lo!? I was drinking coffee!“
O-kay, like, overreaction! Probably in major denial mode, and does in fact have a serious drinking problem. And like I said, she took it out on my hair.
I didn’t get much sleep last night. This morning, I had a 32-ounce iced coffee on an empty stomach.
I’m fishtailing between nausea and euphoria . . .
Someone has trademarked the phrase “The Latte Factor,” referring to his claim that you could save the $3.50 a day you’re spending on little things like coffee, invest it, and wind up with millions of dollars.
I don’t doubt that under a certain set of assumptions, that’s true — although under another set of assumptions, you could invest the money and lose it all, in which case you’ve got no lattes and no money).
From a Dateline NBC interview with fitness guru Jack La Lanne, who will be honored with a star on the Hollywood Walk of Fame on Sept. 26, his 88th birthday:
Keith Morrison: A lot of people, once they start to get older, have things like strokes and heart attacks, high blood pressure, arthritis, those kinds of diseases that are associated with age. Have you had a heart attack?
Jack La Lanne: I can’t afford to. It’d wreck my image. I can’t afford to die, man.
Most of my illustrious career has been spent working or consulting for Fortune 1000 companies. These companies are fundamentally dependent on their computer systems, particularly their online systems, to transact business.
If the systems are down, the business stops running.
In fact, the systems don’t even have to be down to create havoc.
What if the response time is too slow? If you’ve ever done user testing with people whose job it is to enter money-making financial transactions for large corporations, you may have been amazed, as I was, at how fast they are.
Obviously then, the software you build for them has to be even faster; split-second response time is required. If your software is slowing people down, the business is losing money.
Or what if people are sitting around staring at their monitors because they can’t figure out how that great new interface you gave them is supposed to work?
Bad news.
Again there’s a measurable loss of revenue. Because these people are not supposed to be staring at their monitors, they’re supposed to be entering those money-making financial transactions, remember?
I could go on with this, but I think we both get the point: As a technologist working with these companies, you’re held to an exacting standard, because the cost of failure is high.
One evening many years ago, I put a software upgrade into production for a client, a major electronics distributor.
It was a pretty straightforward upgrade and we tested it, but I guess we didn’t test it diligently enough on certain boundary cases, because when I came in the next morning, I was informed that our “upgrade” had crashed, preventing the online system from coming up for an hour until it could be backed out and order was restored.
In other words, we had effectively put the company out of business for an hour, a really expensive mistake. I was further informed that the CIO wished to talk with us in his office once he was finished getting his ass kicked by executive management.
Well, my dick was limp, I’ll tell you.
I took a moment to divide the company’s annual revenue by the number of business hours in a year. According to my calculations, this fiasco had cost about $250,000.
I popped another Xanax and washed it down with a pot of coffee to keep from passing out. I was twitching like a chicken for hours.
Yes, and thanks to experiences like that, I now consider myself a seasoned developer. I try to anticipate the consequences of technical decisions early in a project in an effort to avoid downstream catastrophes.
But I don’t work on mission-critical applications now.
I work on Web applications.
And with different kinds of applications come different kinds of developers.
Most Web developers have worked exclusively on systems where the cost of failure is very low, so they rarely ponder the implications of technical decisions in great detail.
Why bother? What’s the worst thing that could happen?
Well, the Web site could have unpredictable access times, it could scale poorly, users could be unable to navigate the interface.
But so what?
As I write this, people still expect Web sites to have unpredictable access times, to scale poorly, and to have confusing interfaces.
Developers aren’t penalized for this; it’s all factored into the equation, as though improving the situation is beyond human capacity.
He who pays the piper is calling for a low-quality tune.
Okay, part of the problem is that most clients either don’t know any better or aren’t willing to pay for better.
And, you might say, why should they when users are still more than willing to forgive them for mediocrity?
But here’s the real problem:
Very few Web developers have had the edification that comes from blowing away a quarter of a million dollars of someone else’s money in an hour, not to mention the resulting shitrain that descends over the land.
Because if they had, they’d be a little more careful next time.
Here’s a fun story about the benefits of really holding people accountable for shoddy workmanship.
In The Innocents Abroad, Mark Twain wrote about King Xerxes, who in the 5th Century BC ordered a bridge of boats to be built across the Hellespont:
A moderate gale destroyed the flimsy structure, and the King, thinking that to publicly rebuke the contractors might have a good effect on the next set, called them out before the army and had them beheaded. In the next ten minutes he let a new contract for the bridge. It has been observed by ancient writers that the second bridge was a very good bridge.
Res ipsa loquitor.
Thus spoke The Programmer.
