The best talk at WWDC 11

I was happy to see that Apple had recently posted all the session videos from WWDC online, available for free to Apple developers. It’s great that they do this, because a lot of us *cough* aren’t able to attend for one reason or another, but we still want to know what’s going on.

One talk in particular stood out, and there’s no question in my mind that this is single best talk at this year’s WWDC. It’s called Writing Easy-to-change Code: Your Second Most Important Goal as a Developer by Ken Kocienda. If you have an Apple ID to login, then you can watch the video from this page. To get this out of the way, the most important goal is to ship products, and that’s not what the talk is about. The talk is a motley collection of simple, great ideas that outline a powerful philosophy of programming.

Why this Talk is Good

The thing about this talk is, if a younger version of me watched it, I wouldn’t have been that impressed. Why? Because everything Ken says is common sense. You hear the idea, and you say to yourself, “well yea DUH of course.”

So I want to defend why this talk is actually very good. Because there are a ton of programming ideas that sound good, and seem to make sense – but in the end, only a few of them stand the test of time. I can now say I’m becoming an older programmer, having been at it for over 25 years now. I’ve been doing this a long time, and I’ve had some time to very seriously test out a number of philosophies.

And the points that Ken makes are both time-tested truths, and at the core of what is good about good code.

The title of the talk is “easy-to-change code.” And if you think about it, this one simple moniker really captures the main idea behind so much of the evolution of programming. We want code to be readable, maintainable, debuggable, feature-addable. If code is easy-to-change, all of these other properties need to be there as well (e.g. if your code isn’t readable, I would not call it easy-to-change). Moving from non-object coding to object-oriented thinking; using an actor model for parallel processing; adopting standards for interfaces on many levels; test-driven development: all of these ideas are essentially designed to help us make code easier to work with / easier to change. So this is an example of one simple idea being at the center of a lot of useful ideas, and, although you might not see it directly in the talk, a lot of the ideas presented are at the core of a set of other, related ideas that naturally would follow if you sat down to ponder all the consequences.

If I write any more, this post will be longer than Ken’s talk. I have to add the qualification that I disagree with maybe 5% of what he says, but I’m probably wrong about that 5% 🙂 Go check it out!