Hacker News Reader

Comment by timr | Hacker News Reader

"fretting too much about the apparent greenness of the grass on the other side of the fence is always a warning sign of procrastination, doing so when you already have three years of Rails experience and know exactly where its pain points are is really a sign of procrastination. Just build the thing already! You will save time by working in a framework that you already understand."

I don't disagree, but I think I should point out the danger -- this is exactly how programmers become dinosaurs in the industry.

Next time you feel the urge to make fun of that guy with 20 years of C++ experience, keep in mind that he was probably just working in a framework that he already understood. One day you look up from your last successful project, and everyone is 22 years old and coding in Blub. Only those old guys are working with Rails....

View on HN

I can't argue with this in general, but it hasn't got much to do with the case at hand. Worrying about the day when Rails will be a dinosaur technology is an even more extreme form of premature optimization. And if you are trying to hedge against Rails' obsolescence, why would you pick Django? Shouldn't you pick something sufficiently different that it isn't routinely mentioned in the same sentence?

I'm not worried about it, and I realize it's a digression. I'm just saying that if every time you face one of these decision points you go with the technology that you already know, then you're optimizing for something different than career longevity, and it will come back to bite you. The point is that there's always a tension in this industry between learning new technologies and being maximally productive.

That said, it isn't "premature optimization" to diversify your portfolio of technologies as much as possible. It's premature to try to guess the Next Big Thing and use it for your project, but that isn't what I'm suggesting. And in any case, five(-ish) years ago, you might well have faced the choice between using Perl and using Rails for a similar project. That decision would have proved fateful.

five(-ish) years ago, you might well have faced the choice between using Perl and using Rails for a similar project. That decision would have proved fateful.

Let's keep some perspective here. Rails, Django, and the various Perl frameworks each have their rabid partisans, but they represent fairly tiny variations on a single theme: Client-server web applications. There is very little danger in overspecializing in any one of these. You can move from one to another with ease. They employ similar concepts, by necessity. The HTTP and the SQL and the CSS knowledge all transfer over. The browser is still the browser. My god, I wish the browser was changing fast enough that I risked becoming a dinosaur!

I suspect that there is far more danger of overspecializing in, say, MySQL than of overspecializing in Rails. Databases are huge, complex beasts with real differences in their implementation and operation, and they can have profound impact on the performance of your app. (Just ask an experienced Oracle DBA. He or she will talk your ear off, as happened here on HN the other week.) The difference between the various brands of glue that we use to stick our databases to our web servers? Not as fundamental as we'd all like to think. The stuff I do today is not much different from what I and my colleagues were doing in AolServer Tcl in 1999. (Now that is dinosaur web technology!)

The real danger of becoming a dinosaur happens at a higher level. I'm a professional PHP programmer now, god help me, but I'm not afraid of missing out on the Great Django Revolution: When Django is finally ready to call my colleagues and I, I'll listen, and I'll probably understand what it's saying because it'll still be speaking the language of server-side web apps. The real danger is that one day I'll wake up and realize that the interesting problems have moved off the web server entirely and that all the fun is in standalone Javascript apps, or iPhone apps, or Microsoft Surface 3.x apps, or Scala applications embedded in your shoes, and server-side web app development has become about as exciting as Internal Revenue data processing (which it resembles in many ways).

When I really want to diversify, I'll look at Javascript or Objective C or embedded systems programming. I won't look right next door. That's too easy. Alas, this means that my track record of never getting around to learning Python may continue. :(

That's why you play around with new technologies in your free time. Then, when it's time to build your next big project, it's not "I have three years experience with X and none with Y; which should I use?" but rather "I have three years experience with X, but I've been playing with Y for the past year and I think it's a better fit."

Yes, yes. The problem comes when you don't have much free time. When you're working on a successful project, it will consume every hour that you can devote to it. If you then want to have a life outside of computers, you find yourself having to make a conscious choice between your main project, and learning new technologies.

This problem becomes far more acute as you get older. When I was in college, I had all the time in the world to experiment with things. These days, I don't have much energy for computers when I'm away from work.

"Only those old guys are working with Rails...."

And django.

Reply on news.ycombinator.com