Hacker News Reader

Comment by japiccolo | Hacker News Reader

While I agree with the general idea of the analogy (that great programmers are effective, no matter how many specific years of experience they have with language X), it doesn't quite hold up. It would really only be accurate if learning to be effective with brown/walnut/etc. could take several months, as is the case with some programming languages/tools/methodologies.

View on HN

What is this language you've been using that is so terribly different from what people learned in college that it takes the months to be effective, not even efficient? Off the top of my head, I produce.... prolog and haskell. It's very, very unlikely you'd apply for a job that was looking for those languages without realizing it.

If you know java, you know python, and you know c, and you can think in algorithmic rather than implementation terms, then you're good for pretty much anything. The hard problems are the same everywhere: cache invalidation and naming things. (I'm only partially kidding.)

EDIT: Besides, if you're hiring for 3-5 years, the advantage language knowledge grants candidates becomes minimal, and the ability to apply old lessons, to learn, to adapt, dominates. If someone has issues learning a language, there are probably more striking problems that would prevent them from getting the job anyway.

The two you mention (Haskell and Prolog) are great examples of languages where people can actually have negative impact for a while until they really get up to speed with the language. Pretty much any functional or declarative language fits that bill, and definitely any Lisp. Maybe not 6 months, but definitely at least a couple of months to start contributing a lot of additional value (in addition to getting set up with the team's environment and workflow).

Amazingly, even if someone does learn Java, Python, and C, he or she is not necessarily able to generalize that knowledge to other languages, or even to larger-scale projects in those languages. For example, I wouldn't want to take someone with a lot of Python experience and a semester's worth of C, and put them on a large-scale firmware project or Linux-kernel-hacking project. There are a lot of ways somebody who thinks they know C could mess up a project like that.

In general I agree with you: a truly smart engineer can pick things up as they go, especially on a longer time frame. However, this isn't always the case. Though my perception is admittedly warped a bit working in startups, where you need people to hit the ground running immediately.

Well, you have to remember that very few places uses lisp for that very reason (the benefits don't outweigh the training cost), and the few production bits of lisp code I have seen work like java (albeit less object-oriented) with macros.

Second, I only mentioned C because of its use in understanding computers. Memory management is definitely a skill that people should (but often don't) learn in college, at least to understand what's happening when your GC hits some GC-unfriendly code. So I agree that memory management (via C) is a niche skill, so the analogy outlined in the original post doesn't apply... but quite honestly, how many people on this site write C regularly enough that lack of knowledge of C is going to seriously impede them? The vast majority of jobs I see are for PHP, Python, Java, and C#, at which point the largest impediment is the time it takes to get the O'Reilly book.

I agree that most tools that are similar are fairly easy to switch between: PHP/Python/Ruby/Groovy, and Java/C#/C++, all imperative, OO, etc. Also, from a tools standpoint, Rails guys can use Django and vice versa, pretty much the same, for sure.

It also sounds like you agree that that's not so easily done with (quoting myself from above), "some programming languages/tools/methodologies." So sometimes, sometimes not.

So... we agree? :P

Yes, we agree. :)

Reply on news.ycombinator.com