In his post on migrating from Ruby on Rails to Expression Engine, Dan Benjamin references the following quotation from Jianzhi Sengcan:

The Path is not difficult for those who have no preferences.

I think I’m just going to sit and contemplate that for the rest of the day.

I really wish I’d gotten to attend Merlin Mann and John Gruber’s SXSW talk on blogging for a living. Mann posits that the successful formula is: obsession plus voice. It reminds me of what I usually tell people who are wondering what kind of career they pursue, which is: do the thing that you can’t not do.

There’s a lot of misguided career advice out there that suggests doing what you “love”. But there are a lot of people who love to do something but would no longer love it if they were forced to do it for 2,000 hours a year. Loving to cook and wanting to stand in a restaurant kitchen for 11 hours a day are two different things.

So my suggestion would be find a way to get paid to do the thing you can’t stop yourself from doing. The best programmers are people who can’t stop programming. The best writers are people who find themselves wanting to write when they’re doing other things. Do what comes naturally.

I can say for certain that it’s a lot easier to get up in the morning and go to work if what you do at work is what you gravitate toward regardless of whether or not you get paid to do it. That’s more likely to be driven by compulsion than love. Go with it.

This year’s Edge Question is “What have you changed your mind about?” I’ll play along. This is a list of some things I changed my mind about in 2008.

• Database normalization and redundancy avoidance are the key principles in database schema design. I was once fanatical about normalization and did everything I could to avoid repeating data anywhere, or storing aggregated data in the database. My feeling was always that with SQL you could do all of the aggregation you need to, so why risk introducing bugs that result in conflicting information being inserted into a database? What I’ve come to see is that performance, in many cases, wins. If you have to denormalize to get the performance you need, do it. Storing the atomic values that can be used to derive the aggregated values is usually necessary, but if you have to store the aggregated data to keep customers happy, do it. I’ve come up with a number of other cases where keeping redundant data can be helpful in improving performance, and I’m just going with it. Normalization is a means, not an end.
• JavaScript is harder to debug than CSS. At one time, I avoided using JavaScript at all costs due to cross-browser issues. These days, there are a number of popular JavaScript libraries that do an outstanding job of abstracting away browser differences and working around for browser bugs. Today, if you’re willing to use a library, dealing with cross-browser issues in JavaScript is no big deal. On the other hand, I’ve been shocked to see how many incompatibilities there are between CSS implementations in browsers. The number of hours I spent (or watched others spend) dealing with annoying CSS issues in 2008 astounded me. And there’s very little out there that has been done or can be done to make these issues go away. CSS depresses me.
• Texting is not particularly important. See this blog post to see why I changed my mind.
• You don’t have to make programmers do any programming at interviews. Experience this year has shown this not to be the case. I used to think you could just ask them about projects they worked on, talk about their responsibilities at work, and ask general technical questions and still get the information you need. I now know that in order to successfully interview a programmer, you have to watch them write code, or at least pseudo-code. Even the simplest programming demonstrations weed out a large majority of applicants.