There has been an opportunity in my workplace of late to apply for a change in role: the sort of change which, yes, does have a pound symbol attached, but a modest one, the point of the exercise having as much to do with getting to face the kind of challenges you really fancy waking up at 3am worrying about, rather than ones you would hate to wake up at 3am worrying about, but wake up at 3am worrying about anyway. (With sentence construction skills like these, no one need fear my application progressing too far.)

It’s been interesting to observe the various approaches of those colleagues who have applied, and, out of deference to their privacy, I shall say nothing about any of them, save that the person who thinks they’re most cynical and defeatist about it is in fact hopelessly outclassed in negativity by another applicant. I… looked at the forms, shall we say, and thought about how I would fill in a couple of the blank boxes presented.

Two hours and six words later, I had failed to find in myself a single redeeming quality. Even my old PE teacher did better than this, and I was a real challenge (he wrote: “Mike is hopeless at this subject and knows it, but I enjoy his dry sense of humour”). Had I spent any longer on the matter, it’s safe to say I would have had to resign immediately, on grounds of sheer honesty.

So if, in a totally ahumorous, ruthlessly fact-based sort of a way, I cannot think of one good thing to say about myself, what hope could there possibly be for me as a humorist, when invention, wit, agility of imagination and mastery of the over-extended nonsense metaphor are all marvellous but essentially adjuncts to sound underlying structure of the prosaic old ahumorous sort? Wilde, of course, maintained that he reserved his true genius for his conversation, which has ever since provided hope to generations of bad writers who, when drunk, think they’re funny (self, of course, excluded: when drunk I am hysterical).

So which will garner more pounds sterling: funny “ha ha” or funny “I take my job extremely seriously, and regard it as my life’s work to improve human lives through intelligent application of technology, right up until the Singularity, for which I will be right at the front of the upload queue”? And is that even a particularly important question to ask (if you work for a mortgage broker, please note that the sentence in which this parenthesis is embedded is humorous and should not be understood as implying financial irresponsibility on the part of its author, who would like to borrow six times his salary to live in a Zone 6 shoebox, pretty please with icing on) in these days of personal fulfilment plans and tailored dieting?

Well, who knows, who can say, and I expect as with so many things in life we’ll find out sooner than we could have worked it out. Good night and good luck.

Anonymous Technical Guru Colleague ‘L’ says he’s seen this three (count ‘em) times, all on rhel environments running under VMWare. Harrumph.

That sounds rather harsher than I mean to be; sorry. The root cause is that I spent a good few minutes today reducing an (admittedly already overlarge) JUnit test case by a substantial percentage thanks to this little idiom:

try {
couldThrowCheckedException();
} catch(Exception e) {
fail("Exception thrown");
}
I think the forces, right or wrong, operating in the minds of coders when they write this are as follows:

• checked exceptions are a nuisance, they hinder your smooth progress through code (I know, I know), and they’re not what you’re interested in because this is a positive test-case, right?
• Eclipse helpfully offers to surround the exception-throwing call with a try/catch block. How handy! It also offers (I think as the first option) to add a throws clause, but no one seems to choose that. It’s the path of least resistance, so let’s do that and worry about it later.
• They’re not consistently looking at the output of their JUnit (perhaps they’ve been hypnotised by the green bar) — if they had to rely on the text output, they’d be frustrated by the loss of that juicy stacktrace in e.
• They’re not writing the parallel failure cases. If they were, they’d have had an interest in the exception and might have chosen to do differently in the success case.
• The difference between failure and error is not well-understood. In one sense I sympathise (not green == bad), but the distinction between failure and error is an important one — an error may mean you don’t understand your application or the use of a library it depends on as well as you think you do; a good failure (in development, I mean) means your suspicions were right and it could go wrong like that: in other words, it affirmed your understanding rather than contradicting it.

I’d be interested to see whether TDD made a difference to these forces; I know it did for me, and made a huge and fairly immediate difference to all aspects of my code (mostly, I have to say, quality; but also simplicity). TDD draws the coder into the code; you can’t just write to a spec and be done with it. I would hope that it also draws coders into a more rewarding coding cycle; they get to write more code, they get to really understand what’s going on, the tests document the system in a way which makes sense to them, and they get to creatively challenge the design.

Cue Eliza Doolittle singing Wouldn’t it be lovely …