Jeff’s Austin Blues

Years ago I heard a tale, perhaps apocryphal, of a business consultant who’s client wanted to go computerized. He knew that the computer salesman was overselling and would under-deliver, but nothing he could say changed their mind, they had to computerize their accounting. So he told them they needed to regularize their accounting, clean it up, and put standard procedures in place, “for the computer”. He had been telling them that for years, but now he had a lever. So for months there was a big push to clean up their accounts so they could go “computerized”. When everything was ready for the computer, he sat down with the company owner and showed him that they were already realizing all the benefits claimed for computerization without the costs of the computer.

As I noted in a previous post, my adaptive RSS reader, Amethyst, is running too slow. So in preparation of moving the CPU/time intensive operations into C, I centralized them in one class and started working out the raw SQL that the C code would need. It’s ugly but it works, it approximately 7-10 times faster, has the potential for even more speed, and is done in less time than researching relational database access from C would have taken. Yes, I can probably get even more speed by going to C, but right now it isn’t worth the additional time. Plus the framework I developed for a realistic benchmark can also be used by the test code. Nice.

In Taking a Smoking Break… For Non-Smokers, Vlad Doleza makes a case for taking a 20–30 minute break every 90 minutes or so at work. The claimed benefits are:

• You will be more relaxed
• Your concentration will improve
• You will accomplish more

I’ve been trying it for a week. I think I’m more productive in my work, but one thing is clear, I’m less tired at day’s end leaving energy for other things outside of work. So I’m certainly more productive at life.

This is the title of a cut on the new Ray Wiley Hubbard album. “Momma cried and Daddy burned when I told them what I learned … Live and die rock and roll, it ain’t something you control.” I love music, but I’m not gonna die if I can’t play it. This is the difference between a musician and a wannabe. Ray Wiley Hubbard is a musician. I may be a musician wannabe, but I am an honest to God engineer. I want to build things and get very grumbly when I can’t. I’m always looking for a better way to do things, whether it’s a better route to somewhere, a better way to cook a dish, a more elegant solution to a bit of code, whatever. I see an oddball wheelchair and I want to know it works better than the standard design and in what ways.

“Maybe follow your bliss” is a description of parts of the path, maybe “Do what you can’t not do.”

A neighbor told me this, perhaps apocryphal, story.  He was the right age to have been there.

In World War II a group studied where planes were shot.  When they finished the study they were going to armor the places most commonly hit.  That is until someone pointed out that their sample only included planes that returned.  I.e., these were the places where a plane was hit and was still functional enough to make it back.

In a podcast by people from Adaptive Path they were talking about their failures and maybe even why failure was good.  One of them said that failure is often a sign that you were trying new (and presumably, interesting) things.  It occurred to me that success is a drag, if you succeed you now have a legacy app to maintain!  Whereas if you fail, you can run on to the next interesting thing.  My experience is that the only way to escape a successful, now legacy, app is to leave the company.  And even that doesn’t always work.  Over ten years after my first for-pay programming job, a summer job, my employer tracked me down and wanted help.

While walking around Town Lake, Austin, TX (thank you Lady Bird Johnson), I was listening to a podcast by several members of Adaptive Path on their failures. One of the programmers told that he usually warns the customer that at some point in the middle of the project, he will hate them and they will hate him. I had the impression that usually this is around some particular topic, not just in general. It occurs to me that they have found the high energy topic(s). Now that it has been identified, is there a way that they can resolve the forces involved (think Design Patterns) in a better way? Time for some truely outside the box thinking. If there is that much emotion involved, the payoffs could be fantastic.

Years ago P.J. Plauger made the distinction between casual users and novice users. Casual users are often very computer literate, just not frequent users of the program in question. For most people, a tax program like TurboTax or Tax Cut is used just a few times, once a year. CPAs and bookkeepers are doing some kind of tax returns almost year round, they are the expert users. Most of the rest of us may have been using each version of TurboTax for over ten years, but we are still just casual users. People don’t stay novice users forever, but they can be casual users for years. How should programs be written to help casual users?

Kathy Sierra talked about Just In Time (JIT) learning, learning as you are ready and motivated for it. As opposed to learning for some supposed future use (i.e., most school learning). So how to tell when you are ready and motivated for it? I don’t have all the answers, but I see bits and pieces in all kinds of places.

Joseph Campbell in “Hero with a Thousand Faces” talks about entrance challenges. These are barriers or obstacles that aren’t significant in themselves but prevent the totally unprepared from wandering into a situation that only luck could bring them through alive. There are plenty of waking world examples, age restrictions on driving, size/height restrictions on amusement park rides, and entrance requirements for various schools. The difficulty is making them appropriate (i.e., fair) rather than arbitrary. Age may be a mediocre way to measure maturity, but it is easy to apply and we all know what the passing score is.

The teaching materials must be right at hand. Kathy gives an example of a small booklet on one aspect of horsemanship on durable or disposable cards you take with you to the riding area. A book on the reference desk of the library doesn’t count.

A common way to handle this is graded lessons. When you have demonstrated a certain level of skill, certain lessons or teaching materials become available to you. I think with a multi-dimensional notion of skill, this could work well. I’d like to see someone apply it to the search function in help systems. Usually these returns all possible matches, many or most of which describe how to manipulate entities the casual user has never touched, has no use for, and is probably overwhelmed by.  And there needs to be a way to indicate, “Show me more” and “Show me all”.  The boundary between known and not yet known needs to be fuzzy and permeable, with intention you can go any where, but you are kept away from the cliffs while on a Sunday stroll.

Donald Knuth’s excellent book on TeX had the equivalent of “Here Be Dragons”, a dangerous curve sign in the margin for paragraphs you could skip on first reading.  The index used bold page numbers for the definitive reference for a feature.  Very helpful.

The speaker in podcast I was listening  to recently talked about learning and on-line resources like Wikipedia.  Serious illness can be a strong motivator.  He talked about people with a high school education teaching themselves to read research papers in juried journals on a medical or other problem.  Not all at once.  They would start with something written for a lay audience, look up words and concepts new to them, often on-line, and then tackle a more difficult article.  People with a “12th grade reading level” learned to read at a post-graduate level in this one area.

How to roll all these bits into a coherent idea is something I’m working on.

Somewhen back in the late 70s or early 80s I read an article entitled “Eleven Tips for Meeting the Guru” or something similar. I think it was in the “Whole Earth Review” or “CoEvolution Quarterly” magazine, however I’ve never been able to find it again. One tip that has stuck with me is, “What the guru tells you is true, your task is to find what it is true of.” I’ve found this to be true on several levels.

Spiritual teachers are trying to teach a worldview. There are two bits to this, a way to reach it and what it looks like. Usually the way is essentially a condensed version of how the guru reached the worldview. Usually they leave out the detours, deadends, etc. However, remember that a detour is usually there to go around something you might rather avoid. Sometimes the direct route is not the best route. The other bit is what it looks like when you arrive, whatever path you took.  All of this is a mix of the metaphorical and the concrete.
Many writings or speakings are reactions to or arguments against some other writing or speaking. If you can find that article/speech/whatever, often the arguments make more sense. For example, the Software Engineering Institute’s Computer Maturity Model (SEI CMM) is a reaction to the utter chaos and unpredictability of software development with no process. It is predominately about making software development managable and predictable. So it collects numbers and objective evidence. It also assumes software development is like manufacturing, it is a repetitive, assembly line process that we need to squeeze the last bits of productivity out of. The Agile Methods (AM) are a reaction to CMM.  If you’ve never ecountered CMM, much of the AM rhetoric won’t make sense.

Every program, every programming language feature, every policy and procedure attempts to solve some problem. The problem may not exist. The problem may be so infrequent it isn’t worth codifying a solution. The solution may be bad or worse than the problem. But always keep in mind, “What problem is this trying to solve?” Same applies to laws.