Jeff’s Austin Blues

In over thirty years programming I’ve noticed that very often the first task to run is the last one to work correctly (i.e., pass testing). From naive managers you can get a lot of gold stars if you have the first task that compiles and runs. And you get more stars for coming in weekends and fixing problems. Plus every manager knows you from your presence in emergency meetings on Monday about how to get back on track. You get to be a hero.

Of course, if the task had been designed properly in the first place, it wouldn’t have been “Runs First”. And good unit tests would have caught any errors before they blew up on the weekend. No heroes;) And every manager wouldn’t know your name. What glory is there in being done early and on schedule?

Pity.

Jon Udell has a very interesting entry on Multitasking tradeoffs: individual versus group productivity on his blog. Read the comments, they are useful too.

A programmer colleague once observed, “You get more out of a line of code than anyone I know.” At various times this has felt like a criticism, at others, like a complement.

Note that my code was not obfuscated or deliberately opaque, it just had the fluff and the fat trimmed out. No dead code to be eliminated by the compiler. If the whole equation fit on one line, it was on one line. Etcetera.

When I first started writing technical articles, I found that my first drafts were too dense for easy readability by a factor of about two. Essentially, there was no redundancy. Every idea was there once, precisely expressed, each word selected for exactly the right meaning. It makes it just about impossible to contradict myself, but the reader has to understand each word exactly the same way I do. And there is no redundancy to help correct misunderstandings. So that density of writing is not desireable in explanatory or tutorial writing.

So a question is, where is it appropriate? Or perhaps, where is dense/rich expression used?

• Math and Science: think how much verbiage has been written explaining e = mc² or the wave equation in quantum mechanics.
• Standards: here the lack of redundancy may be deliberate so the standard can’t contradict itself. There is often an unofficial section explaining the official section. Standards aren’t light reading, readers are expected to already be an expert, and a glossary in the back explaining terms is acceptable. There are standards for standards! ISO standards in English are required to use British spellings.
• Poetry: same as math and science. Especially if it is not written in contemporary English. I read an analysis of Dante’s Inferno that devoted a page and a half to the first four lines of the original Italian, explaining the exact meaning of the words and their connotations.
• Sacred Texts: same as science, math, and poetry combined. I recently read an analysis of the First Pillar of Islam, six pages to explain two short sentences of Arabic.

Admittedly my code is not as dense or rich as any of these, but what can I learn from them about writing rich code?

Maybe the solution is to write the code succinctly, with no wasted motion, no superflous lines, use good formatting and naming conventions. And then write a commentary on it. Supposedly comments and documentation do this, but in my experience, not enough effort is put into them. Too much commenting obscures the code. Not an improvement. Documentation is separate from the code and often the distance grows as the code evolves and the documentation doesn’t. Donald Knuth’s Literate Programming is a good, though partial solution.

I’m not sure what the solution is, but it isn’t dumbed down code.

Kathy Sierra has another nice blog entry on “Are our tools making us dumber?” Quoting from life:

That night, you’re helping your 12-year old son with his math homework when you realize–in horror–that while he’s quite good with the calculator, he couldn’t multiply two three-digit numbers using only paper and pencil if his Wii depended on it. These tools were designed to make us more efficient, so that we can focus on something more important than the tedious task of, say, giving change, organizing source code, and doing calculations. But are they helpful timesavers, or are we dumbing ourselves–and our users–down?

One way around this particular problem is realizing that you are dealing with levels of abstraction. In this case:

• The level in question, e.g., multipling two numbers.
• The level below, e.g., multiplication with pencil and paper.
• The level above, e.g., computing the cost of a home loan by multiplying the monthly payment by the number of months in the loan (30 year loan = 360 months).

If you keep all three levels in mind as you work the problem, aids like calculators will make you faster, not dumber.

Other threesomes are:

• Computer variables:
  1. the value (98.2)
  2. what it represents (the patient’s temperature)
  3. how it is represented (the bits and bytes in binary/octal/hex)
• Computer code:
1. What you are trying to do (multiply two numbers)
2. How to write in the programmng language (total = payment * duration;)
3. The machine/assembly language generated by the compiler (is the generated code correct?).
• Program libraries:
1. How you expect the API to be used (e.g. what functions are worth optimizing and for what load).
2. How to code it correctly.
3. How you use any libraries or system calls.

Know where you are and what surrounds you and you can go farther and faster than finding out the hard way by bumping into the sharp edges.

Some bozo is bombarding this blog with comment spam. In the past 24 hours, there have been over sixty comment spams. So new policy, you have to register and login to post comments. If I can figure out how to blacklist the IP address, I’ll open up the policy again.

I’ve been looking into a potential program – brainstorming, developing use cases, researching technology, etc.  Plus looking at how it should fail gracefully.  The usual.
Along the way it occurred to me that I also need to figure how for it to succeed gracefully, i.e., how to prevent it from becoming a victim of its own success.  As with failure, there are several parts to it: scale well, provide depth so a beginner doesn’t soon reach its limits, allow extensions so the expert doesn’t soon reach its limits.  Not only must the capabilities be there, the user has to know they are there.  So how do we let the user know as she/he is ready without overwhelming the beginner?  Clippy has clearly demonstrated that is not the answer, but a more understated implementation may be more successful.

Richard Hamming gave a fascinating talk at Bell Labs many years ago on his observations about what lead scientists to do great work.  There are many great ideas here, several of which I have also stumbled upon too.  Probably the best is seeing defects as opportunities for breakthroughs instead of just accepting them as problems to be worked around.

I was using Blosxom, but there were problems with it spiking the CPU usage. It was a package I installed so support was on me. I’m now using Word Press which is supported by my hosting site, so the burden of support is on them.