There are times when static type-safety feels a lot like shopping with an obsessive-compulsive friend. Whenever you consider buying something, he forces you to scribble it onto a list; whenever you change your mind, you have to cross it off. If you complain, he starts to laboriously tell you the benefits of keeping the list: you can easily check your shopping cart against it, it makes you seriously consider each item you buy -- and, once you've discovered your shopping patterns, you might be able to convince the storeowner to rearrange the aisles for your convenience! In the meantime, every few seconds you're forced to edit the list when another item catches your eye. For a programmer, paying that sort of careful attention to detail has many advantages, so it's almost always worthwhile. Compilers and other static analysis tools can catch thousands of mistakes that would otherwise wreak unpredictable havoc, but they usually require programmer input, like variable declarations and type annotations. Most programs benefit from these abilities, particularly since they often also enable the compiler to make certain powerful optimizations. Even better, when code is stable, these features are easy to take advantage of; it's usually just a matter of writing down what the programmer already knows to be true. Moreover, programmers often have a good conception of how their programs will be used, so they can carefully craft them from the beginning to exploit the expressiveness of the language. The trouble is that programs are rarely made entirely out of solid, carefully-written code. New code can be very volatile, written for rapid prototyping or against shifting requirements. Exploratory programming is poorly served by having to conform to a disciplined coding practice: the structure of the code is too unstable to be usefully depended on, and, as a supplemental system, it usually doesn't need to be efficient. Most programmers would choose to use a more flexible language in these situations if they could, but that's a practical impossibility when the cost of integrating multiple languages into a single program is very high (as is normal). I believe that that particular tension can be eased substantially using some already-established techniques -- namely, a disciplined combination of dynamic typing and type inference -- but I also believe that it's merely a part of a much larger deficiency. A great deal of PL research has gone into the pursuit of greater and greater efficiency and correctness. This work is commendable; few would wish it away in favor of a return to wilder, slower, and buggier days. However, I fear that something is lost in this: that programmers are often overwhelmed by their languages, and that these advanced abilities are often made without enough consideration for usability. Languages like Standard ML are hard to match in the expressiveness of their module and typing systems -- and yet beginning students are continually turned off by arbitrary fits of syntax and unhelpful type-checkers. Austin's Speedway group is well-positioned to investigate solutions to these problems. Austin has a long and successful history in building compilers and designing language features to simplify programming practice and improve program performance. I would like to investigate using these techniques to lower the performance cost of agile development, as well as to simplify the interactions between tightly- and loosely-written components. My interests are in helping programmers to write better programs more efficiently and more effectively. I've been doing that, in a small way, since I first wrote libraries for a specialty text-adventure language (TADS) in high school. I've done a great deal at Viz to improve the company's product; I've written architectures, and I've written applications against them. Many of my proudest moments, however, have been improvements to the company's SDK, letting other people do their work more easily and more expressively. That's the work I love to do, and I hope to continue doing it at Austin.