Strong opinions, weakly held

Tag: philosophy (page 2 of 2)

Eschew preferences

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.

Do what you can’t not do

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.

Educate, don’t advise

Last week I posted about the dangers of giving advice. I’ll say flat out that I’m not a fan of advice, even though people ask for it all the time. As an alternative, I would recommend education.

The other day a client who’s building an application in Rails sort of apologized for using Subversion for version control and said they were looking at migrating to Git. Other Rails developers had apparently asked why they weren’t using Git, and he seemed a bit abashed by it. I could have advised him to migrate to Git, or that he should stick with Subversion, but instead I explained how Git differs from Subversion, and what people like about it. Given a better understanding of how they differ, he was able to make his own decision. (He stuck with Subversion.) In the end, it was consideration of his own circumstances that led to what was probably a good decision. Some people working on the project use Windows, and aren’t interested in the headaches of using Git on that platform.

To be honest, I only realized that I prefer educating to giving advice recently, but I have been explaining why I’m against giving advice for a long time now. Advice is cheap and rarely productive, and nobody ought to be taking it without understanding the thought process of the person giving it. That’s particularly important because for all the value of an independent perspective, the other side is that advice givers often lack key pieces of information. The reasoning behind the advice is where the value is, because it enables you to see how the advice may apply to your specific circumstances.

I suspect the motives of people who give advice. Nearly all advice boils down to “be more like me,” and many advice givers are interested in the ego boost that comes from having people listen to the advice they’re giving. Hearing the words, “If I were you,” I generally want to flee.

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.

Strong opinions, weakly held

A couple of years ago, I posted a link to an article which said that the essence of wisdom is strong opinions, weakly held.

Tyler Cowen points to an article from the New York Times which says essentially the same thing in a different way. It explains that most people who claim to be undecided really aren’t and that more importantly, not recognizing your own subconscious leanings makes you more captive to your own biases.

Here’s the money quote:

Scientists have long known that subtle biases can skew evaluations of an issue or candidate in ways people are not aware of. But the new study, appearing Thursday in the journal Science, suggests that professed neutrality leaves people more vulnerable to their inherent biases than choosing sides early.

So take a position, even if you’re not completely convinced, and then carefully evaluate that position. You’re more likely to arrive at a better answer than if you ride the fence.

Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑