Ted Kaemming's Blog

I’d rather be challenged by somebody, rather than have somebody say, ‘Dude, where are you going to have drinks after the show?’ I love a spirited debate as much as anybody. I even like being wrong, if something can make a good case … on something. In a lot of ways, that’s what I do professionally, traveling. I’m confronted by my own ignorance or misunderstandings all the time.

A portfolio of work is a curated experience. It’s an applicant’s chance to shape the way that I’m viewing his or her approach, methods, process, and best thinking; but oftentimes, a portfolio only contains final pieces, as applicants are overly concerned about presenting perfection. Polish doesn’t communicate process though, and therefore I’m left with only part of the story. Messy problems — and how applicants work through them — can show a great deal more in a portfolio than one finished, airtight solution. It’s then the applicant’s job to curate those into an experience for the portfolio viewer.

I think time is kind of like that. It’s hard to tell how it’s best spent until a real person is faced with a decision to actually spend it or not spend it. At GitHub, we have a very simple voting/prioritization system: whatever people decide to work on is a priority, by definition. If something is interesting, more people end up working on it. This doesn’t mean there’s no priorities. It just means we find out about them instead of deciding on them.

Your most vivid fears are almost certainly not the most important ones.

We pay attention to the loud and the urgent. This can lead us to ignore the important and achievable paths open to us — because we're so busy defending against the overwhelmingly dangerous (but unlikely) outcomes instead.

Telling an inspiring story about a beautiful design feels disingenuous. Yes, we all strive for beautiful code. But that is not what a talented young programmer needs to hear. I wish someone had instead warned me that programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements. Of course I wouldn’t have believed them. It seems that pragmatism and humility can only be learned the hard way. I don’t know how to explain this in a case study. War stories do not instruct, because in retrospect the mistakes seem obvious. It is hard to convey the extent of the minefield of mistakes laying in wait.

On Google: We did not enter the search business, Jobs said. They entered the phone business. Make no mistake they want to kill the iPhone. We won’t let them, he says. Someone else asks something on a different topic, but there’s no getting Jobs off this rant. I want to go back to that other question first and say one more thing, he says. This don’t be evil mantra: “It’s bullshit.” Audience roars.

About Adobe: They are lazy, Jobs says. They have all this potential to do interesting things but they just refuse to do it. They don’t do anything with the approaches that Apple is taking, like Carbon. Apple does not support Flash because it is so buggy, he says. Whenever a Mac crashes more often than not it’s because of Flash. No one will be using Flash, he says. The world is moving to HTML5.

Also worth reading: Steve Jobs and the Economics of Elitism in the New York Times.

I think that it’s a real possibility that in 10 years, general purpose computers will be seen as being strictly for developers and hobbyists. The descendants of the iPhone and iPad and their competitors will rule the consumer market and people will embrace the closed nature of these platforms for the same reason that Steve Levy hyped Palladium almost 10 years ago — because what you get for trading off freedom is reduced risk. There will be few (if any) viruses, and applications will “just work.”

General purpose computing is too complicated for most people anyway, and the iPad’s descendants along with similar competing products from other companies will offer an enticing alternative. So I see the death of the traditional, open personal computer as a likely occurrence.

Besides thinking people should write JavaScript when they need JavaScript, there are a couple of reasons why I feel that way: offering built-in systems for automatically doing XMLHttpRequests and other effects would tie Django to a particular JavaScript toolkit, which I think would be an awful idea. Or else it would require us to maintain code in the framework for all of the popular JS toolkits, which would be an even worse idea. It would also mean getting opinionated and telling people how they should develop, which is an absolutely terrible idea.

jQuery landed in the Django trunk today, as a result of changeset 12297. While I like jQuery (and that's an understatement — I do almost all of my personal work with it), this seems to me like a particularly bad idea.