There is a natural tendency in most people I know to gravitate towards voting as a management tool, particularly in situations where there is a vocal disagreement. This is probably because it’s part of the western culture to favour democracy, and because it works a lot of the time.

However, there are times when voting is definitely not the right way to make decisions. What are the factors that make it so, and how do you figure out whether voting is the right tool for your current problem?

I’ve finally given in and installed FeedBurner on Inter-sections. The main reason for that was that WordPress didn’t allow me to specify how big the RSS summaries were going to be. Now, I don’t want the RSS Summaries to contain whole articles, because I kind of like to see hits arriving here, but at the same time, the puny line-and-a-half that WordPress was willing to put out was just too miserable.

So good news. FeedBurner is now installed. It should be transparent for everyone - I’ve installed a WordPress plugin that magically fixes up all the WordPress RSS URL’s to point to FeedBurner instead. I’m still tweaking some settings on the feed, but it should all be finished sometime today.

Thanks for reading this blog!

The weaker Sapir-Whorf hypothesis, also known as “Linguistic Relativism”, proposes that the “facilities” of your language influence the kinds of thoughts that you will have, that your thoughts are effectively guided in a certain direction based on the language you are using. This is well-known to Rubyists, particularly in the RSpec/BDD world, so I won’t talk too much about that in this article. There are many other articles covering the interactions between RSpec and Sapir-Whorf and BDD.

What I’d like to talk about in this post is another much more subtle, but powerful impact of Sapir-Whorf.

ComputerWorld just published an article called The 5 users you meet in hell (and one you’ll find in heaven). In this lovely piece, they argue from the point of view of helpdesk support workers, and describe various ways for support workers to “handle” difficult user species. It even describes a “Dream User” type that all support workers want to have as a customer at the other end of the line.

In my perhaps not so humble opinion, this article misses the point completely. The reason they miss the point is that this article is, like many other articles of its type, focuses on categorising users (the customers of a helpdesk) as annoyances that need to be “handled” in particular ways. I’ve done internal helpdesk support. I’ve done customer support. I’ve done application support. One thing that any person in any “support” role should learn is that their role is, indeed, to support people. Not to “handle” them, but to help them. Wake up, support staff! Your job exists because of these “lusers” you despise. If they weren’t there, neither would you.

In the spirit of the thing, I thought I’d write a brief article exposing 5 support personas, and how to handle them, from the point of view of a user. I’ll even throw in the “Dream Support” person for free.

People compare programming languages all the time. Often, comparing languages can feel like comparing pieces of string (as in the expression “how long is a piece of string?”). There doesn’t seem to be much common vocabulary to rely on, particularly when explaining things to a non-programmer.

If you talk to computer scientists (the kind who like to study languages as forms of sophisticated imperative expression), you will get some interesting concepts about the ’power’ of the programming language (e.g. does it support continuations? closures? recursion? functions as first-order variables? etc.). These discussions tend to be really interesting (if you get the jargon), because the topic of programming language design is a pretty neat pseudo-philosophical one. However, they don’t much help in the pragmatic decision between building your company’s core product in Java, Ruby, or PHP (as an example).