What have you changed your mind about?
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.
1 Comment