Virtual Pragmatics

NLBP: Next Logical Break, Please.

I was working the list of completed issues and testing them out on the staging server when I ran into a question that I wanted to ask of the guy sitting right across from me.  We went through a dialogue I've been through hundreds of times, as both interuptor and interuptee, where the interruptor asks something like 'Got a minute?', which might mean 20 seconds or half-an-hour, and the interuptee says something to the effect of 'not now, give me 5 minutes', or something to that effect, to allow time to complete a thought/process step/whatever.

This time we joked about the need for vocabulary for this, and we came up with the phrase "Next Logical Break, Please", and its shorthand, "NLBP" to handle the interuptee's side of things. 

Run it and see if it works...

One of the bad habits I've developed in being a coder for almost twenty years is, when faced with a question about whether a piece of code does what it is intended to to, I will often skip analyzing it carefully and just run it to see if it will produce the expected output. This is quick, easy, intuitive... and it is a cancer on your analytical skills. It's cheating. It's like starting on an exercise in a textbook, but then looking in the back of the book for the answer. And it's dangerous: Code increasingly is used to monitor and control all kinds of real-life situations, and you want better guarantees than, say, 'it worked the third time we tried it', or 'it's worked for everything we've tried so far', which is about as strong a guarantee as you can get from just testing running code. I do think we should test. And I do think that there's a point where we should 'Let the machine do the work', as Kernighan and Plaugher advise in Software Tools. But I also am seeing the value of developing the coder's equivalent of 'mathematical maturity'.

The ability to read a piece of code and build a correct mental model of its execution is something that builds mental strength, and is worthy of cultivation.

And when I find my copy of 'Programmers At Work', I'll replay Bill Gate's quote on this from 1986 back when he was fresh from coding.

Career Calculus

Eric Sink (who is not a legend) has some interesting and valuable things to say about learning and about managing your career and your work day. A quote from the article:

The best learning occurs when we choose to process a mistake with a mentor or peer. Unfortunately, this goes against our natural tendency. When we foul something up, the last thing we want to do is shine a light on it so everyone can see what a bonehead we are. What we really want to do is cover it up and hope nobody notices. But in doing so we miss a huge opportunity to increase our cluefulness.

I definitely have a built-in desire to cover up my mistakes... and some of my greatest moments, or at least the ones I am most proud of, involve owning up to falling short and taking responsibility for it. Some of the deepest and best lessons in life come from such times.

Comparing XP with 'Code Complete'

Dave Hoover has written a nice article comparing the advice of 'Code Complete' with the practices of XP.

The article was written in surprise at Code Complete's author's (Steve McConnell) distaste for XP.

I think Mr. McConnell's distaste is rooted in his preference for structure, expressed as certification. He argues for professional certification of developers ala civil engineers, due to computing's growing impact on society. I respectfully disagree with this view. I do not believe certification to be a panacea for the ills of software development, based on my experiences with certification and certified people. Certification does not by itself grant the insight, conscientiousness and experience required to be a 'good' developer, nor does possessing certification guarantee that one also posesses these qualities.

I say this with great humility. Steve McConnell wrote 'Rapid Development', 'Code Complete', and 'Software Project Survival Guide', and I didn't. All three of these are among the books I most highly recommend, and are among the most useful books I've found for planning and executing software projects and code authorship. I would not discount his views lightly.