What should I do for OSCON?

OSCON proposals are due in a few weeks, what should I do? I tend to undervalue my past work, or that nobody wants to hear about THAT again, and worry that my current stuff is incomplete. So some more objective suggestions are welcome.

"Simple Ways To Be A Better Programmer" was popular so I'll probably submit a tweaked version of that. Or maybe split it up into two tutorials, one about "code" and one about "people". I'm always surprised at how many people find the refactoring and effective version control stuff so... new.

I'm tempted to submit something like "Human Interface Design For Programmers" to run through how the basic principles of interface design provide a way to think about what is and is not good style and good APIs. There's too much "this feels right to me" going on resulting in a lot of non-productive arguments that cannot be resolved.

Something about testing, I guess. I've been reading Steve Krug's "Don't Make Me Think" and I'm very impressed that he wrote a book about the web without mentioning any code at all! Thus it is universal and timeless (uhh, in web years anyway). I've been pondering how to do that with testing.

I'm submitting a talk to a govt workshop in Norway about how CPAN illustrates a way to coordinate without centralizing. A grand talk on how CPAN works and why it's so damned awesome and why everyone else keeps screwing up their attempts at reimplementing it would be nice.

An idea I got from Josh Schachter that wasn't accepted at Pgh.pm might be fun at OSCON, "That Sucked". It's a "how I learned from failure" discussion, but if nothing else it's nice to have a bunch of gurus up on stage talking about how they fucked up, just like mere mortals. I'd love to run a session of that.

Something several people have asked me to do is a specific tutorial for a specific sort of newbie programmer. That being a tutorial on how to go from writing single file programs to multi-file distributions and all the necessary complexities that go along with it.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

One thing which surprises a lot of developers after they've been doing testing for a while is discovering that testing doesn't just make their code more reliable, it makes them a better programmer. Your functions tend to do less, but do it better. You learn to decouple things. You learn that your function with 13 arguments might be poorly designed. You learn how to write less code and get more done. You learn how to refactor safely. You design better APIs. You learn first-hand the pain of violating t

Yes, something that shows the symbiotic relationship between tests and coding and debugging would be useful. Not sure how to formulate that.

I'd never heard of the Liskov Substitution Principle [wikipedia.org], but after reading the Wikipedia article it sounds like it's related to the protocol good neighbor principle "be lax in what you receive, strict in what you output".

Liskov is something that confuses a lot of programmers because it's often explain in arcane ways. Condider the explanation from the Wikipedia link you provided:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

Well, that's true, but since most of us aren't computer scientists, it can be confusing, particularly since many programmers don't realize that classes are merely types and operators are merely shortcuts for met