Hacker News Reader

Comment by nevir | Hacker News Reader

Don't hire someone for their knowledge in a specific language! (Unless you're doing some very core work in that language)

Hire someone who knows the concepts behind most languages, and can easily understand new ones.

View on HN

I don't understand how people believe this is universally good advice. Perhaps if your company is large enough that you can reasonably pay new employees for weeks or months before they're actually productive, I can see this being feasible. But that's not most companies.

Keep in mind that this also likely impacts the productivity of at least one of your current employees, and if it doesn't, your newbie's language acquisition is not going to happen as fast, and their ramp-up time on your projects is going to be longer.

There's a big gray area between well-funded startup and well-established business where an entirely unproductive employee can have a non-trivial impact on your cash flow.

No employee is going to be productive on a new codebase for weeks or months, regardless of the languages they knew coming in. And they're still going to be a drain on resources while coming up to speed with the code base, even if they know the language.

The sooner you realize this, the sooner you'll understand what your real hiring requirements are.

I once eavesdropped on some HR people talking shop, and heard the unsupported claim that thanks to employment laws in the US, new employees are rarely profitable until their second year with the company, which is why it is important to hide the company's warts from the new employees.

After that first year, it isn't quite so crucial to keep you happy. That explains why you never get the raise you were expecting after the annual reviews. You are now profitable, therefore paying you more would reduce profits and make you a less valuable employee.

And so we must go job-hopping.

Its ALWAYS weeks or months before somebody is really productive. They're already learning the build/CI/bug reporting environment anyway. A new syntax/debugging/deployment scheme. The language syntax is really pretty small potatoes.

It really, really does not take "weeks or months" for a skilled programmer to pick up a new programming language. If you're using intrusive and opinionated frameworks where you have to learn a ton of conventions, that increases ramp-up time. If you're crossing paradigms, e.g. from Java to Haskell or from Python to C, that increases ramp-up time. But if you're just picking up a new programming language, say a switch from Python to Ruby? You can be productive in a week. I've done it before, more than once.

The difficulty isn't in finding people with specific experience, the difficulty is finding people with a solid enough understanding of essential concepts to be able to do good work regardless of the environment they're working in.

If a company doesn't have enough runway to have a new hire be unproductive for a few weeks, I'm not sure if that company can afford to have employees yet.

I can learn a new language well enough to be productive faster than I can become comfortable with a new codebase or with all the tooling built around it. I think this is true of many developers.

> months

that's a drastic overestimate. at some point, procedural languages really are all more or less the same. sure, there are different notions of types, variable scope, modularity/oo-ness, etc., but someone who knows a bunch of languages knows what concepts to get straighted out from the beginning and can be productive in days. if you find someone who knows a handful of procedural languages and haskell and lisp, they'll be able to pick up whatever language you're interested in.

now, picking up a bunch of toolkits is a different matter, because they really can be just a quirky as their designers want them to be. for example, using gson yesterday, i ran into a bug with json serialization that was pretty quick to diagnose by stepping through a few lines in the debugger, but it took over a half hour of searching and browsing api docs to find out that Maps weren't being serialized properly because i hadn't called GsonBuilder.enableComplexMapKeySerialization(), which it seems like really ought to be enabled by default.

then -- and not even finally in general, just finally for the sake of keeping this post briefish -- there are frameworks, which are like a perpendicular axis to the original language question. perhaps someone really familiar with rails or django and a little java background would be a better choice for a java project built on play than an expert java desktop developer with no server-side experience.

so in summary, if you can find someone who has basically already built your exact project before, yeah, you'd better hire him or her, but otherwise, intelligence, the ability to figure new things out, is always going to trump experience along any single line of expertise that one can attempt to draw through a software project.

I generally agree with the caveat that you have in-house experts in the language and toolchain (or can afford to grow some). You may also need some experience in the applying that language to your domain, depending on how challenging the problem is.

I agree that any decent programmer can pick up a new language pretty quickly.

However, I think that it's not really about the language, it's more about the libraries. Knowing all the utility functions that exist and how to use them is based on experience, you don't pick that up overnight.

tl;dr: bright inexperienced people pick up the language quickly and then rewrite library functions that already exist.

But experience in one language should give you a good idea on what library functions should exist (unless you are crossing paradigms). At this point, you can just search (or ask a co-worker) how do I do X in <new language>, and go on your way.

Agreed. Having that skill is what separates the mediocre from the exceptional.

Reply on news.ycombinator.com