Man flies 193 miles in lawn chair

Man flies 193 miles in lawn chair

Kent Couch is my hero.

Last weekend, Kent Couch settled down in his lawn chair with some snacks — and a parachute. Attached to his lawn chair were 105 large helium balloons.

Destination: Idaho.

With instruments to measure his altitude and speed, a global positioning system device in his pocket, and about four plastic bags holding five gallons of water each to act as ballast — he could turn a spigot, release water and rise — Couch headed into the Oregon sky.


I’m confident my wife would never let me try this stunt. And frankly I’d be really embarrassed if I died in the attempt. But this is the sort of thing that I’ve dreamed about since I was a little kid. And Couch had the guts to try it. Twice.

Couch is the latest American to emulate Larry Walters — who in 1982 rose three miles above Los Angeles in a lawn chair lifted by balloons. Walters had surprised an airline pilot, who radioed the control tower that he had just passed a guy in a lawn chair.

I suppose there will be other copycats, probably not including me (alas!). It’ll all be fun and games until some guy goes up with a case of beer for ballast and then falls out of his chair unconscious and unable to pull the ripcord on his chute while he plummets to his death somewhere over Nebraska.

Then there will be laws passed against elevating one’s self in a lawn chair without a license, or crossing state laws while reposing on outdoor furniture.

But until then, my hat is off to Kent Couch, my design hero of the day, for courage in the line of reclining, and for elevating his game above and beyond the call of common sense.

Adium – “Don’t Change” vs. “Change All”

Before I pick on Adium, I have to first issue this disclaimer: I like it. I use it. It’s good software and mostly does all the things that I want.

But here’s my nit. Today Adium informed me that a newer version was available. No prob. Let’s upgrade. It downloads the new stuff, does its magic incantations, then hits me with the following dialog box:


Adium has been updated.


Do you want to allow the new version to access the same keychain items (such as passwords) as the previous version?


This change is permanent and affects all keychain items used by Adium.

I realize that the ensuing click of my button will have sweeping implications and CANNOT be undone. But I’m OK, because I DO want to allow the new version to access the same keychain items as the previous version. My answer is, “Yes”.

“Don’t Change” “Change All”

Huh?! Wait. My answer was “Yes,” not “Change” or “Don’t Change”! What’s change got to do with it?!

Lemme think… Must remain calm… If I keep the same keychain items, that sounds like “Don’t Change” doesn’t it? I want them to stay the same. But the warning says, “This change is permanent,” suggesting maybe that “Change All” will do something to the newly upgraded software to bring all the old keychain items with me. But change what? The new empty keychain list to the old keychain list?

All I want is for all my old configuration stuff to follow me over here. I want to “Allow” or “Don’t Allow” or even “Yes” or “No” will do.

It’s a small nit, I suppose. But it’s really bad interface design. Don’t ask the user a Yes/No question and then provide two buttons that have meaning primarily to the programmer.

I click “Change All” because I believe that sounds more like “Yes” than “Don’t Change.”


All of my online friends are still with me. I think that means that my new version has access to the same keychain items as the old version. Whew! “Change All” made everything appear the same to me.

Now if I just knew what a keychain item was…

Programming: Nature or Nurture, Part II

My most recent post to the PPIG mailing list…

On Jul 4, 2007, at 10:55 AM, Frank Wales wrote:

Charles Knutson wrote:
I believe there is a taxonomy of four types of people, relative to
professional software construction:
1) Those born to code, who need almost no coaching;
2) Those born capable but in need of training in order to be successful;
3) Those not really born to it, but who can be trained sufficiently to make a living;
4) Those whose brains are really not wired to build software at all.

As a matter of interest, do you have a sense of how the general population
is distributed across these suggested types?

Rather than just categories or types, I’d actually propose a spectrum
of capabilities, with people who just ‘get’ computer technology at one
end, people who would sooner eat lint that use it to check their C
programs at the other, and the substantial mass of people bulging
somewhere along the middle. (Of the spectrum.)

I’d speculate, completely without anything beyond years of experience
and arrogant presumption, that the “just get computer technology” end
of the spectrum glows with about 5% of the population, the “couldn’t
write ‘hello, world!’ despite years of practice” end is dimmed by maybe
15% of the population, while the remaining 80% of the population huddles
around various quantumly-distributed embers in between.

I think the end groups are inherent, while the huddles are plastic.

Of course I have no objective evidence for what the actual distribution might be. If anyone has seen any empirical take on this distribution, it would be very interesting. I could easily buy the idea that the top is 5% and the bottom 15%. I also concur completely with the idea of a spectrum. My taxonomy was more of a highly granular way of describing such a spectrum. My apologies to anyone who was expecting a fist fight 😉

Two last thoughts on inherent aptitude:

1) I’ve recently run into students who took the first semester programming class at BYU, did well, got their ‘A’, and then washed their hands of the field and went off to study business or something else. Clearly they are capable of programming, at least at the entry level, but the biggest dissuading factor to them was the inherent motivation (or lack thereof). One of them told me that after spending 15 hours on a programming project, and finally getting it working and passed off, they felt like they had been robbed of 15 hours of their life that they would never get back! That was such a news flash to me! In *my* experience, every program or project I ever finished has carried with it some sense of euphoria and satisfaction that seemed to make all the pain worthwhile. And much of my programming time has been somewhat rhapsodic, like a runner’s high. So while I don’t consider myself to be the most gifted programmer (or even necessarily a member of the first group) I have always been quite satisfied and happy with the process of constructing software.

2) I just started reading Stephen King’s “On Writing.” Interesting to find this quote on page 4 (substitute “computer programmers” for “writers”):

“This is not an autobiography. It is, rather, a kind of curriculum vitae — my attempt to show how one writer was formed. Not how one writer was *made*; I don’t believe writers *can* be made, either by circumstances or self-will (although I did believe those things once). The equipment comes with the original package. Yet it is by no means unusual equipment; I believe large numbers of people have at least some talent as writers and storytellers, and that those talents can be strengthened and sharpened. If I didn’t believe that, writing a book like this would be a waste of time.”

Just a bit more grist for the mill.

Professional software developers: Nature or nurture?

The following is an email I just posted to the PPIG mailing list, in response to the following comment:

For the record, I believe anyone can learn to program at a professional level. The question is, are they willing to put in the time to acquire all the chunks needed to be an expert? Unfortunately, we can’t force our students to put in the time.

I’m not convinced that absolutely *anyone* can learn to be a professional X (whatever X is). I think there are some who are really just wired to do other things. But I am confident that there are varying degrees to which inherent aptitude plays a role, and similarly varying degrees to which effective learning experiences contribute to facilitate those individuals who can, in fact, be successful at profession X.

As evidence, I offer the following non-empirical anecdote. I started programming in 1973, when I was 13 years old. Our high school had a timesharing account on a mainframe at the University of Northern Iowa, and a DecWriter with a suction cup modem and a rotary phone with a dedicated line to the university. About a half dozen of us math geeks gathered daily in a room to play with the computer (which largely consisted of playing Dungeons and Dragons and Star Trek, with intermittent fits of attempted software design and code construction). Several of my friends just seemed to have the knack right out of the chute. We’d dumpster dive at the university for discarded manuals, and that was all Brian and Doug needed to build software. I tried desperately but couldn’t get it beyond a fundamental level. The other guys were more or less like me, in love with the technology, but not fluent with the incantations.

Years later, in my second semester at the University of Iowa, I had a really well constructed and well presented Computer Science class that focused primarily on design. During that semester, the light came on, and I got it! From that semester it was simply a matter of learning new skills and piling them onto the foundation I had now acquired. I had a very successful professional career building software (HP, Novell, various small companies and consulting gigs), picked a few graduate degrees along the way, and then retired to the university to stop producing and begin pontificating. 🙂

As an epilogue, of the group of math geeks that gathered together daily in high school to play with the DecWriter, all but one of us acquired degrees in Computer Science, with the other one (Brian) doing Electrical Engineering.

My personal experience is that I was always fascinated, I was obviously capable, but I needed someone to throw the switch for me to understand how to become self-sustaining after that.

I believe there is a taxonomy of four types of people, relative to professional software construction: 1) Those born to code, who need almost no coaching; 2) Those born capable but in need of training in order to be successful; 3) Those not really born to it, but who can be trained sufficiently to make a living; 4) Those whose brains are really not wired to build software at all.

Just my two cents. Your mileage may vary.

Dr. K’s first patent! :)

United States Patent 7,236,742

System and method for wireless data transfer for a mobile unit, patent No. 7,236,742, invented by Eric S. Hall of Provo, David K. Vawdrey of South Jordan, and Charles D. Knutson of Salem, assigned to Brigham Young University of Provo.

We’re pretty stoked. This is the first patent for Eric, Dave and me. We submitted this thing on June 12, 2002, back in the heyday of the Mobile Computing Lab when Eric and Dave were my M.S. students. So hey, only five years to find out we actually have something that the technology transfer office at BYU can license to somebody. Good thing the technology moves so slowly while we’re waiting for the patent process to pan out… 😉

Anyway, I just wanted to share. Dave’s friend Ricky saw the announcement in the Salt Lake Tribune this morning, told Dave, who called me. Apparently this is how you find out that you’ve been awarded a patent. 🙂

Congratulations are especially in order for Eric and Dave. They did most of the real work and deserve most of the credit.

In case any recruiters come across this posting while googling for Eric and Dave, Eric Hall is a Ph.D. student in Biomedical Informatics at the University of Utah. David Vawdrey recently received his Ph.D. in Biomedical Informatics from the University of Utah, and is heading off to his first faculty position at Columbia University in New York City. They both did their M.S. in Computer Science in the Mobile Computing Lab at BYU under my tutelage. Hiring either of these guys would be the smartest HR move your organization ever made.