Hacker News Reader

Comment by human_error | Hacker News Reader

> Hiring for Go — I wouldn’t even know where to start

Let's go with metaphors. Programming languages and driving a car are similar things. When you change your car from Toyota to Audi, you don't learn everything from scratch. You just spend sometime to get used to the car (wheeling, brakes etc) and then you're all set. Programming languages are similar. When you switch from language A to language B, you don't learn programming from scratch. So, when you want to hire someone to code in Go, you just hire a developer and tell them they're going to code in Go. After getting used with Go, they would be all set.

View on HN

In principle, I agree that picking up programming languages for a good programmer shouldn't be a challenge but this analogy doesn't go too far. There are fine nuances about a programming language that you need to learn to be a good programmer. Whereas a car is mostly a commute tool for many. You can switch a browser like a car, but switching a language is a bit more involved.

I agree with your point, but Go in particular doesn't seem very different from, say, C/C++. I think the average programmer who knows C/C++ can pick it up rather quickly, even though going from Java to JavaScript takes significantly longer.

Picking up, while easy, isn't terribly useful. You have to know the non-obvious pitfalls and the 'right' way of doing things.

You also need to develop a full understanding of the package/library/framework ecosystem, which can take years. This isn't transferable knowledge, either, but it's absolutely vital to understanding a language.

Knowing that requests is a great python library, for instance, and knowing when (and when not) to use it isn't going to help much when picking up Ruby, let alone something like Go or C.

I've seen good, experienced programmers pick up new languages and consistently step in the many of same traps that beginners do, simply because those traps aren't very obvious.

I think what you're describing is "being an expert" rather than "being proficient."

If a project requires expertise in a specific language then sure, shoot for "an X programmer" (there are very, very few of these in reality). Otherwise "a programmer" (who is good) will almost certainly be able to perform the job, and do it well, all other things (e.g. motivation, interest in actually using the technology in the project, etc.) being equal.

It seems that the 'Effective Go' article was written to avoid the pitfalls. I agree with your point, but I don't think it's a very strong one.

http://golang.org/doc/effective_go.html

> There are fine nuances about a programming language that you need to learn to be a good programmer.

On the other hand language is an investment. Switching a language in the same paradigm is more like maybe learning a local dialect of dialect of English, new words, new pronunciation. Say you are moving to Australia from US, you might have that issue. But if you think it worthwhile it is an investment.

But that is for when the paradigm is the same. Object oriented, functional, dynamic types vs static types, logic programming, declarative (SQL) those are like different languages French, Spanish, etc.

Reply on news.ycombinator.com