I haven’t yet had the opportunity to work with Ruby, but my [admittedly limited] understanding is that it’s somewhat similar to Java. But you do bring up a good point about the popularity of a language not being the only measure of how fast one can pick it up.

If you think your team can ramp up to Ruby that quickly, consider that future projects won’t include the learning time and would be faster still. Speed obviously isn’t the only important measure, but it’s definitely something to consider.

On the matter of attracting great developers, I agree that language has an effect. Something I just thought of is that keeping your products in a legacy programming language will eventually cause maintenance costs to increase. In our case, moving to ASP.NET will allow us to find new developers with a little more ease.

Interesting post as it’s something that every new software project must consider. I agree that the key is to hire versatile developers instead of programmers. Versatile developers won’t have a problem picking up a new/niche language.

Well known languages/frameworks don’t always offer the fastest time to market. For instance, my team knows Java very well but doesn’t know Ruby or Rails. But because we have some very good developers my gut feeling is we’d be able to launch a product with RoR faster (or maybe just as fast) than if we launched another Java based webapp. With versatile devs you should be able to get the best of both worlds - fast time to market and maintainable code.

A colleague of mine suggested that the way to attract great developers is to build your app with technologies that appeal to them. Basically the applicants self-select based on your tech choices.

This might not be very practical for a number of reasons. As a secondary option he suggested simply looking for certain technologies on applicant resumes, even if you’re not planning on using those technologies. In any case, finding good developers is hard.

Thanks for the post.

-David

Handling an unexpected interruption is a bit tricky. You need to be able to estimate how long you’ll be away from your work. I’d say that, in most cases, someone interrupts you to ask a quick question that has a quick answer. So you can go ahead and answer it.

But sometimes you’ll have to deal with a client request, be pulled away for a lengthy meeting, or realize that quick question doesn’t have a quick answer. As soon as you realize you’re going to be away for a while, you need to start preparing.

It’s perfectly okay to tell the person interrupting you that you just need a few minutes to finish things up. Sometimes when I do this, the person continues to stand over me, at which point I politely suggest that I’ll give them a call when I’m ready.

Not only does this allow you to get back into your work quickly, but you’ll also have a clear head to handle the interruption.

I suppose we could also get a bit more creative and allow for a full set of ASCII values to be put out on the display, but at that point, I think it would be better to consider a different type of display.