I'm not sure I can narrow it down to a single thing. I think productivity is the product of optimizing a very complex multidimensional space. I'll enumerate a few of the axes of that space, but it surely will not be an exhaustive list.

Once, a long time ago, when I was at the MIT AI Lab and Patrick Winston was its director, Pat came into my office and saw me typing away. "Kent," he said (and I paraphrase from memory, since of course I did not actually record the conversation), "in your lifetime you will probably accomplish three times what I have, just because you type three times as fast as I do." I don't know if that was a completely fair assessment, but it was not without merit to consider as a criterion. Competence at the basic mechanics of manipulating a computing interface, both at typing and at one's word-processing tools (I use Emacs, not because of the silly politics over open source, but because of its long-standing commitment to catering to experienced touch typists rather than catering to those who are simply bumbling along slowly with point and click).

Being "Type A" helps, too. I'm not sure how other people define that, but I take it to mean "always having to be doing more than one thing at once". I watch TV (usually news or information shows) while I work, except in certain rare cases where I can't concentrate with noise in the background. This means I'm taking in information all the time at the same as I work. I don't usually have time to read, and I read so much online that I don't find it a relaxing side activity; however, I listen to book tapes in the car when I drive around. Sometimes it's fiction that I wouldn't have time for other times. Sometimes it's educational material.

I'm also very conscious of parallelism in my life. Suppose I have two tasks to do: wash the dishes and send an email. It's important to send the email first. Why? Because it might be that when I'm done washing the dishes, a reply will be present. If I do things in the other order, it's a certainty (since i won't have yet sent the email) that a reply will not be waiting. By simply reordering events, without doing any extra work, I can improve throughput.

Have multiple tasks available to work on. Some years ago, I saw a talk by Isaac Asimov in which he made the same observation. He pointed out that he hated working on what he was supposed to, so he would strategically place other things that were also important around the room and when his eye would wander, looking for something to do that wasn't what he really should be doing, he'd at least find some other thing that needed doing. And eventually things would get done anyway. Also, sometimes you just can't do one thing all the time. If I have a large writing task to do, I try to find another project of a different kind (e.g., programming) to interleave with it. It helps break the monotony. If you don't use techniques like this, you simply end up wasting your slack time, and that time is never recovered.

I prefer Lisp, primarily because it is the most pliable. It comes with a number of features built in that I like, but if I don't like those features I can reshape it to be something different.

In most other programming languages, the character of the language syntax dominates how you express yourself and you can't really rise above it.

Every language, even Lisp, gets some things wrong. Or maybe it's just that one given set of syntactic choices can't be right all the time. But Lisp gives me the greatest ability to overcome its own weaknesses.

There are actually a large number of other things I like about Lisp but the other main thing I like is that it's a language for expressing "what I want it to do" not "how I want it to do it". I regard most languages as focusing on implementation. They make you lay out data in precise fashion so that you control the location of every bit. This is like trying to be the president of a multinational corporation but still having to look over the shoulder of every clerk typist to make sure they are doing their job. To really rise above a complex project and see it from a higher abstraction level, you must give up control of the details, and Lisp lets me do that in ways other languages do not.

Oddly enough, I don't think the world is working toward any major productivity boosts of the kinds I would have expected ten years before.

I think the availability of faster and faster processors is mostly how we get productivity boosts any more, and I feel like it's so hard to have "being smart" overcome the sheer brute force of a faster processor right now (perhaps until we reach the hard barriers inhibiting processor speedups when speed of light effects start to come into play) that any strategic approach to productivity improvement is becoming something of a lost art. It's enough just to buy better hardware.

The software products running on those processors seem to me personally to be worse and worse. But maybe that's just me. Perhaps I was raised for a different style of architecture and perhaps there are people who are being served by modern architectures. No matter how "point and click" everything gets, I still don't understand why someone who is a skilled expert would want to take the time to lift his or her fingers from the home row, grab the mouse, move it a measurable distance and press a button, when one can just press a few keys on the keyboard, yet typing speed and all-keyboard interface are rarely emphasized in modern environments.

Also, though there have been many advances in compiler technology, most of them focus on such small gains that again I think processor technology is outrunning them.

I see two classes of problems: limitations of imagination and limitations of budget.

For the first part, limitation of imagination, I would say that management failure to understand what a programmer does and what a programmer is capable of doing is bad. Managers makes two errors because of this: they ask unreasonable things of programmers, and they keep programmers from doing reasonable things. Both of these can be very unfortunate.

A close second in this category is programmer inability to understand what they themselves are (or should be) capable of doing. When I was learning to program, everyone was a generalist and people were really taught programming from first principles as a problem solving activity. Today, more people can learn programming easier, but what is meant by programming is not what used to be meant. People now think of the ability to make Visual Basic or Javascript produce a UI as "programming", yet many people who can do these things can't program much of anything else... especially if there is not a pre-packaged interface to doing such things.

On the side of budget, I have to say that the open source marketplace is I think the single greatest threat to forward advance in computer science. By giving technology away, programmers drive down the price of things. A consequence of this is that it's hard to command a decent price for programming products, and that means fewer dollars to pay for jobs for programmers, if indeed programming can be done as a job at all. Free market business will squeeze every dollar out of something that it can, and if it finds that people will program for free, it will make sure that no one ever gets paid for programming.

Further, I think it's mostly younger and more vulnerable programmers who are idealists who subscribe to the open source rhetoric, while they are in school and at the peak of their game, thinking that earning a few extra dollars is immoral. Later in life, when one may want some liesure time for family, or one may get ill, or one may want to contribute the fruits of one's labor to charity, the true price of having given away so much of value for free early in one's life is most likely to be felt, when one can't really take it back.

It seems there is an endless supply of youth, and so the free software movement continues, for now, to plod along. As it does, though, I think it slowly and quietly strangles the lifeblood of dollars from a community that could be using extra dollars to invest in its future. Instead, since its own dogma suggests that programmers be paid like peasants, compensated for a day's work but not for any value beyond that, there is no slack to plan for future growth, for experimentation, nor even for human error, for medical sickness, nor any other kind of non-task-oriented thing. Programmers are seen as replaceable cogs, and are undervalued because management values only what it pays dearly for, and it is not forced to pay dearly for this.

This is not to say I've never given away a free program in my life. Just that I don't believe the doing of such a deed should be a way of life.

Perhaps because I've worked in and around the AI community for a long time, this doesn't seem as revolutionary to me as it might to people who've come out of more traditional forms of computation. Topics like this, as well as data modeling, Meta programming, automatic programming, and aspect oriented programming are things we've been batting around for a long time. I have complete confidence that these are and always have been productive ways to proceed if we want to take more work off of people and put it into computers.

On the other hand, I do have some ethical worries that tools like this will ultimately replace a great deal of the need for programmers in at least certain areas, and a corresponding loss of jobs. I would like to see a focus in these areas on assuring that these technologies augment, rather than eliminate, existing programming seats.

There will always be new frontiers, of course, but whether those will be things that are what business focuses on, I can't say. Some used to think chess was out of reach computationally, but now it is demonstrably not. Some people probably think "what programmers do" is out of reach, but like chess, I suspect that assumption will fall.

Then again, if the free software movement takes over and programmers are just giving away their software for free and not getting reasonable money in return for their efforts, perhaps having computational substitutes for programmers will put a merciful death to the largely useless profession of "being a programmer" anyway.

I also think these tools will soon create an interesting dynamic in corporations. A couple years back, HP (in its commitment to eSpeak), announced its goal of reducing the time between product conception and product "deployment" to a matter of mere hours. The only problem with this idea is that there is more to a product than mere programming; there are legal issues, promotional issues, documentation issues, and so on. Those factors, while they take time, have always had the amount of time they take dominated by the task of actually making the software product. As programming becomes faster, some of those other factors become the new area that requires business optimization. Perhaps this means we will see a more rigorous approach to documentation and legal issues, in order to bring it in line with the need for fast products. I'm not sure where that will lead things, but I'm pretty sure it will turn out to matter somehow.