Where's Waldo?

Programmers don’t juggle anymore.

There was a time, many moons ago, when you could pretty much assume that anyone who wrote code in a serious fashion knew how to juggle. Maybe not well, but at least well enough to keep three balls in the air for an extended period of time. Maybe even well enough to do passing patterns. You could go to a programmer’s office or desk and find a set of lacrosse balls (much better for juggling than tennis balls, until you miss).

There were other skills that were reasonably common, as well, such as lock picking. It was always nice to know that you couldn’t really be locked out of anyplace. Some programmers had real lock picking tools, while others made do with home-grown picks. It was part of what made the culture of programming somewhat unique.

I started thinking about this recently when I realized that none of the students that are around have any of these hobbies or skills. I wondered what had changed. And then I realized that it was because of the speed of the machines that we all use.

It used to be that part of programming was long periods of waiting. You put together a program of reasonable size, and it had to be compiled, which would take a while. And by a while I mean half an hour or more (I won’t bore you with the tales of waiting overnight for your deck to be run; go ask your parents). You needed something to do for the time it took the program to compile. You didn’t want to start on another program, because you wanted to be ready to fix any errors or start working on tests once the program compiled. So we did things that took enough attention to pass the time, but not so much brain power as to be actually useful. Juggling. Picking locks.

The exceptions to this were the programmers who worked in Lisp, who had instantaneous feedback from their integrated development environments. The Lisp community produced very good programmers, but they were (and this is going to get me in a lot of trouble) less interesting as people. Not only were they intolerably smug about their programming environments, but they didn’t juggle. How could they be real programmers?

Now, of course, our machines are so fast that we all use integrated programming environments that compile the whole system between our keystrokes. These interactive environments have brought all the speed and convenience of the Lisp environment to those of us who use compiled languages. The only time we wait for compiles now is when we download open-source software from someplace else and have to build the entire system from scratch (or while we wait for our IDE to initialize). But that wait isn’t long enough to do anything else other than, perhaps, read some email.

Mind you, I’m not really complaining. I wouldn’t want to go back to the days of 45 minute compiles (especially when those compiles found one typo, which got fixed in a few seconds and then required another 45 minute compile). But all this speed has made the community of programmers less interesting. No one juggles. No one picks locks. I sort of miss it.

At least the Lisp folks aren’t so smug anymore.

One of the suggestions that came out of the discussion when I spoke to the ABCD group was that I hold some sort of open office hours. The idea is that I could just be available for anyone who wanted to come by and talk. No agenda. No plan. Just discussion.

I thought it was a great idea, but wondered if it would work. But I tried it out a couple of weeks ago, and to my surprise (and delight) about 8 people showed up. We had a terrific conversation about what they did, what got in their way, and what made their part of Harvard unique (the person from Classics spends lots of time support odd and non-standard fonts, which was interesting to hear and not surprising once she said it, but hadn’t occurred to me before). The second attempt (last Friday) had about a dozen people, and we ended up talking a lot about open source and the role it could play at Harvard. Both great discussions.

So I’m going to have another. While Friday afternoon is a good time for this sort of thing, I’m going to be out of town (vacation) the end of next week, so I’m going to try varying the day to see what happens. So the next CTO open office hour will be next Monday, August 8, at 4 p.m. in the ground floor Maxwell Dworkin lounge. I’ll put up a sign of some sort (probably on my computer screen) to identify myself.

So come one, come all. The discussions are good, I’m learning a lot, and it is your chance to be heard…

And in an attempt to get some comments, where are some other places on campus that would be good to hold this? I’m looking for someplace informal, that needs no particular scheduling, and where I won’t be embarrassed if I end up spending the hour by myself but where a group of 10 to 20 can sit and chat. I know the Engineering part of campus pretty well (which is why I’ve been doing this in Maxwell Dworkin and Northeast Labs), but it would be good to move to other parts of campus as well. So if you have a suggestion, tack a comment on this post and I’ll entertain other options.

It is an odd thing being the first Chief Technology Officer for Harvard University. There is no history of what the job entails. There is no precedent. I am, quite frankly, making things up as I go along (with the help and advice of others, of course).

But that is part of the attraction of the job. I’ve been a software developer most of my life, and I have always enjoyed the activity of building things. Now I have a chance to build something that (among other things) builds software. Raising the activity up a meta-level means thinking about things differently, and trying things that I’ve not done before.

Now is an exciting time to be in information technology at Harvard. There are a lot of folks who understand that technology is key to the way the university will work moving forward, and are willing to try new things. While there is always some resistance to change (especially at an institution that has been so successful in the past), I believe that there is a real chance of doing some transformative things as CTO.

The purpose of this blog is to communicate what I am doing, and to hear from readers if they think that this is the right set of things to do. I’m hoping that this (along with some other things that I’m trying out) will become a mechanism for two-way communication on the changes that we will be undertaking. I remember once being told that people like change, but resist being changed, so it is important to bring them in to the discussion of what is going to change and how the change is going to happen. I’ll try to be as transparent as I can in writing this, and hope that any readers are honest with me about their own thoughts.