Friday, May 20, 2016

Integrity?

Some years ago, the elder ex-teen (now the mother of two) and I spent some time in Professor Carter’s book integrity, which goes into various areas: intent, due diligence and so on. In other words, integrity means more than simply not telling lies. When put that way it seems obvious, though I don’t usually pay so much attention.

The question of integrity came to mind recently when a friend (I’ll call him “Dieter”) told me about an incident at work. Dieter’s a software guy, like me, and his company’s website (I’ll call the company “JCN”—not the real name) describes a project they did internally. In the article is a statement of why they did this project. The statement is not true; JCN actually did it for a completely different reason than their website says.

JCN’s stated corporate values include words about ethics and integrity, and they have an email “hotline” for that, so Dieter sent them a note pointing out that, paraphrasing, “Our website says the project was ‘first and foremost’ about doing X better, which everybody knows is not true.”

In fact, when the project went “live” at JCN, X was much worse. Dieter admits that today, X is not that much worse than it was before the project. That said, the project really wasn’t about improving X; it was done for a completely different reason.

Dieter acknowledges that this false statement isn’t critical to the company. They’re not promising something their products can’t deliver; nobody’s going to sue JCN or cancel a purchase order because of this statement. But as Dieter told the “integrity” people at his company,

When we make a statement about why we did something, and that statement is not true, that is what makes it a lie.
Please remind me not to get into arguments with Dieter.

JCN’s “integrity” people didn’t see it that way. Dieter was quite bugged by this; he even considered leaving JCN for another employer. But then remembered a couple of things.

  • He’s an American; he knows that his government has killed people in other countries and overthrown democratically-elected governments. But he’s not thinking to become a citizen elsewhere.
  • The prophet Daniel worked for a cruel and arbitrary boss, King Nebuchadnezzar. But would Daniel have quit, given the chance? Probably most bosses at the time were pretty similar, and maybe incompetent to boot. The same thing is probably true of American corporations.
Dieter came to understand that when the company says “integrity,” what they mean is, “Don’t do anything illegal, anything embarrassing, anything that will alienate a customer.” He wasn't happy with that conclusion, but anyway it was a conclusion.

Something else happened that I thought very interesting. After concluding his dialogue with JCN’s “integrity” folks, he told me, “my back stopped hurting!” His back has been complaining (yeah, he’s old enough for that) for some months. The pain hadn’t been debilitating, but he says that was the first afternoon when his back didn’t hurt at all.

What brought relief to Dieter’s back? Was it his acceptance of his employer's Newspeak, like the 5th stage of death and dying, that did the trick?

And what’s the moral of this story? Dieter doesn’t know. Neither do I

Tuesday, May 17, 2016

Confession: taking one for the team

Last week, I sent out a confession at work. I'd read an encouragement to do things like that, and…well, it's pretty self-explanatory. Here's a lightly edited version:
   From: collin <email.address@here>
     To: <recipient-list here>
   Date: Last Tuesday
Subject: Confession

Short version: I did something dumb and confess it.
Busy people can stop reading here, though I hope you read this at some point--maybe while waiting for one of your tests to complete. Details follow.
I picked up a free copy of The Soft Edge when they were being handed out at the cafeteria some weeks back. In it was an encouragement to celebrate successes and also to confess mistakes--especially big successes and big mistakes (cf. “Asoh Defense”).

I saw the power of this a while back when a colleague told me about a mistake, looking somewhat sheepish. “We’ve all done that,” I said. Just to make sure, I added, “I’ve done it myself.”

Well, I’m not the most empathic guy but I felt the weight lift off their shoulders. “You’ve done it?” they asked, incredulous. Yep. It was probably about 20 years ago, but I’ve done stupider things before. And since.

Fast forward to the present. There have been lots of failures in <test case name here>. Some of them happen only when nobody is watching, and have defied analysis. But one of them should have been fixed (by me) right away: burt987303.

It happened in February, then again 8am on May 2. The symptom was a timeout on a “d-volume-create” zapi. “Hey,” I thought, “if the simulator (in this case) can’t come back within 100 seconds, then maybe it died. I could look more, but since it won’t happen again for another 2 months, how much time should I spend on this?”

The answer was: Just a few minutes more--long enough to RTFM and adjust the timeout. You see, it happened again May 4th. You can read <internal document name here>, but the short version is that zsmcli has a “timeout” parameter: I coulda just set that in the command to extend the default 100s timeout.

I’m happy to tell you that I checked in a fix, and that said fix prevented another failure on 5/7 (in <log file name here>, there’s a 118-second d-volume-create execution).

To be clear, the issue was in a test script; the issue wasn’t in the product. I’ve introduced, or incorrectly fixed, product defects before, but this particular issue is in a test case, not in any product sold by my employer.

Is there a moral to the story? Well, the obvious one is to rtfm. Or the help message, as the case may be.

The second is, if you’ve done something like this (it could be more or less dumb; we’re not being precise), don’t feel too bad about it. Performance reviews are over; you could tell somebody. If you’re more senior--or just old--you could tell someone younger; it’ll probably help them feel better. And that in turn might help them think more clearly, too.

cheers,

Why did I say that telling a younger person about your mistake might help them think more clearly? Because when we reduce the pressure they feel to appear perfect (even if the pressure originated inside their own head), they’ll have less anxiety—less stress. Less anxiety, clearer thinking.

It also makes you appear more human, more real. And we need more of that—more live, human connections (as distinct from mere contractural, transactional connections) in the workplace. Out of the workplace too.

Wednesday, May 04, 2016

Too Thorough? part deux

In part 1, I tried to make the point that when a VP or Director calls someone “too thorough,” s/he may mean
“You're giving me too much detail (which I don’t want/need to know); let's get to the high-level information (which I do need to know).”
In other words, sometimes our presentation doesn't match the audience. I resemble this remark, I hope progressively less so as the years have passed.

Another way we're sometimes “too thorough” is that sometimes we spend too much time delving into details that have no bearing on the problem we're trying to address. By the way, I sincerely do mean “we,” as this post attests. About 3/4 of the way through that post, I wrote, “In other words, I was done.” I could have stopped there. Arguably I should have, since I demonstrated that my explanation fit all the facts, and that my code change banished the symptom.

That last sentence is the key. We are not FreeBSD maintainers; we are FreeBSD users. As such, once we know enough to plausibly assert we know what's going on, and to demonstrate that we can make the symptom vanish, we know enough, period.

So why did I continue there? No doubt some of it is a kind of engineering curiosity, not altogether a bad thing. It was exactly that engineering curiosity that drove me to ask my colleague to configure a virtual machine with a disk that could take coredumps, and to find the uninitialized struct component. That is, a certain amount of engineering curiosity is required if we're to make progress. I'll claim it's worse to have too little curiosity than too much, though the truth is probably more nuanced than that.

Early in my career, my manager wrote on a review that I tended to work fast and rely upon experiment. This was a nice way of saying that I sometimes rushed in with an answer without fully assessing the situation. He was right, of course. Back in those days, I would never have written that blog post, because the experimental result would have fully satisfied me; I'd be on to the next thing.

Is it just curiosity then? I guess there's some sort of pride in there, too—the desire for mastery. I love it when I have a complete explanation for how something happened—when I've mastered it. Of course that's not what my employers pay me for; they pay me for solutions to problems that they choose.

The next question for an engineer is: What problems are worth my attention, my curiosity? Senior people are supposed to just know; if something looks odd, is that something worth looking at today, or can it be safely ignored until it becomes a real problem? Is the "obvious answer" truly the answer, or does it simply make the "root cause" harder to find?

Well, we don't know. We need to look far enough to feel confident enough to make a decision, and we need to be lucky enough to not get blindsided too much.

So what's my plan? I'd like to say that the next time I'm hot on the trail of something, I'll stop and think, "Do I truly need to be investigating this?" and make a sober assessment of whether I'm being compulsive, vs. just exercising due diligence.

Maybe that's like saying, "The next time I'm about to say something stoopid, I'll bite my tongue." Does that sound totally useless? Well, if I can remind myself that I have this tendency, or limitation, that's the first step, right? As the engineering guru Clint Eastwood said, "A man's got to know his limitations." Or weaknesses. And of course women do, too.


Well, that was a lame ending. That's because I don't really have this one figured out. Maybe you have some ideas? Leave me a comment :)