Smart people can move between languages easily. It's concepts, understanding of problems and patterns that are important.
I will continue to choose languages that I enjoy and will continue to recruit people who also enjoy the challenge of learning new things.
Sure, a new hire may not have any Scala/Ruby/Erlang experience, but if they understand about source control (you'd be surprised!), testing, enterprise patterns and how to solve a God-damned problem, that's all that is important.
"Smart people can move between languages easily. It's concepts, understanding of problems and patterns that are important."
Important to what?
When starting a company, I think it's perfectly reasonable to worry about how easy it is to find people who know how to use your tools already. Sure, you can always train new people, but it takes time. In a new company, time is usually against you.
Not to mention, you want a good ecosystem for your tools, so you can leverage other people's work.
Important to being a great developer. Languages and tools are interchangeable. It's the basics - the ability to problem solve, learn and adapt to new environments that are truly important and timeless.
Sure, being exposed to a new set of languages and tools can have some start-up penalty. But if it takes someone more than a few weeks (< 3) to be good at Scala, Ruby, Python, etc then there is something wrong. Running through a complete tutorial and solving real problems on a real codebase over a couple of weeks should be more than enough time to become proficient with a specific language if you already have the skills of being able to problem-solve.
Don't confuse choice in your ecosystem of tools for quality. Just because there are tens of thousands of libraries for Java and .Net doesn't mean they are all good or that you can automatically choose the good ones.
The beauty of a more recently popular languages is that smart people tend to be attracted to them and, in my experience, they tend to create better quality libraries and tools, even though they are less of them.
Given the timing of Air Canada's withdrawal from the project and the Great Recession, which has played merry havoc with air travel, I don't think that's what happened.
Especially since ITA is still working on RES. Which is only "1/3" Common Lisp (web based front end is Java centric, back end is Oracle RAC, stateless middleware is mostly but not entirely Lisp).
The problem with that approach is you'll end up with a program written in a dozen different languages and no single person can understand it.
I once worked at place that had a, relatively small, code base that contained more or less equal parts tcl, C, Lisp, Visual Basic, C++, Perl and probably something I'm forgetting due to the fact that the programmers got to choose their languages without any sort of supervision. It was no fun at all for anyone to work with.
Having to support that many languages sounds like a pain. It's also be tough to hire train junior developers who had decent mastery of one language but not several. I'd rather have a junior person really know their stuff in one language than me average in multiple things.
I once worked at a place that had a code base that contained more or less parts in Ruby, Perl, Java and PHP. It was not fun at all to keep enough knowledge in the company over the years to maintain this nightmare.
I was going to mention this too. The blog is "Captain Recruiter". Seems recruiters and HR might be better off sticking to discussion about insurance paperwork.
Really bad advice in the article here. There might be a few cases where the prevalence of a language/availability of help (assuming the language is non-proprietary and has more than a handful of users) might matter significantly (almost always to cater to the demands of individuals misinformed in a manner similar to the author of this article), but for a software project that you intend on maintaining, you should definitely pick a language on its technical and communal merits, and not the skills listed on LinkedIn.
Does everyone have to provide a unique in-depth analysis of the subject before they can make a comment? Maybe the rest of the thread adequately illustrates why advice from a recruiter is not necessarily credible and this comment is just made to tip people off before they get to the bottom of the article. I think that the guy can throw in an off-hand remark without having to provide boons of evidence.
I don't see a problem with pointing out that this guy speaks from the outside looking in.
Largely because it regards developers as a commodity that can be summarized with a few keywords - which is something I have always hated.
Incidentally, I did co-found a start-up in '94 where we chose Java as the platform because we wanted to to do shrink-wrapped server side applications. Java was probably a lot less popular then than Scala is now and that choice turned out to be a huge advantage for us technically. I don't think any of first round of developers we hired had any real Java experience - it really wasn't a problem.
While ad hominem attacks are never good, I don't think this is an ad hominem, but rather an argument based on knowledge/professionalism: A recruiters opinion on programming languages is like the opinion of my baker on medicine: It's nice to hear it, but I don't need a long discussion to decide on their usefulness.
Those who try to hire Haskell devs (and write about it) seem to have no trouble finding experienced people. In fact, it seems like there is almost a "glut".
Wow, an entire article about the costs of choosing an obscure language—which are real enough—but nothing about the benefits. I think everybody here understands that Java and C# are popular, and that this means you'll have an easier time finding libraries and warm bodies.
Here are some other questions the recruiter should have asked:
1. Can you develop your application less time using Closure or Scala than Java? How much less time? Can you iterate faster and try out more ideas before you run out of money?
2. How easy it to recruit good programmers who know Java? In my experience, less than 5% of people who apply for programming jobs know how to reverse a singly-linked list. In a startup, you care about the ease of recruiting 10x programmers, not the ease of recruiting warm bodies.
In short, the article explores half the problem. Without exploring the other half, there's no way to decide which companies should follow this advice, and which should contemptuously ignore it.
Manager-types are more risk-averse than they are opportunity seeking.
But is this an appropriate strategy for a startup? As Paul Graham points out, the average startup fails, so you don't want merely average performance. If you're not prepared to manage risky tradeoffs, you may not be prepared to manage a startup.
Disappointing link. What I would be really curious about is an assessment of (some of) Scala's features and their effect on code readability, reuse, etc.
I don't know nearly enough Scala myself to have a proper opinion on this. From trying out Scala, I remember some features that seem highly dubious to me from a maintainability/readability point of view. In particular implicits and right-binding operators ending in ':' did seem to be asking for trouble, to a lesser degree the sometimes overly punctuation-based syntax ("\:" is the method name of fold left...).
For an article that bitches about Scala too much, the recruiter clearly overlooked another poster child of Scala - Twitter! While the general premise is well intentional, but really, what you need the tool for makes more sense. Sure, FourSquare and Twitter use Scala - but the rest of world's backend needs aren't that special cases.
I hope the op recognizes that organizations are inherently islands and sometimes the smaller more productive ones tend to be little paradises of productivity with no ferry service. Happy swimming there :-)
1) I think people really overestimate the effort required to learn a new language. When I've changed projects in the past, learning the language was much easier than learning the codebase and project/business requirements.
If I was assembling a team of Java programmers today, I'd prefer to hire an excellent Python developer than an average Java developer * . A great programmer can learn a language faster than an average programmer can become a great programmer. The great programmer could be reasonably productive with Java after two weeks, but an average programmer is unlikely to improve their problem solving skills, or their ability to cleanly structure large programs after the same period of time.
* Feel free to replace 'Java' and 'Python' with any two languages within the same paradigm. I don't mean to pick on Java as a language.
2) In the article he's ignoring many advantages that smaller languages have going for them:
- Much, much higher signal-to-noise ratio when hiring: The people who currently know Scala or Haskell learnt it because they love to program – they sure as hell didn't learn them to land a job. You can't say the same about Java, C# or PHP.
- You may make your company more attractive to the best developers: A company advertising for work in Java sounds very average (and a place to work for pointy-haired bosses). It will have to work a lot harder to stand out from the crowd. A company sounds interesting if it uses interesting languages.
- Great programmers will usually prefer to work with languages they are passionate about.
- Great programmers like working with other great programmers. I can assume I'm working with better programmers when joining a Scala team than a Java team. When hiring, you have to work harder to convince me you're good if you are a Java team.
- If you only hire great programmers, you can have smaller teams: ie, you don't actually need to hire as many programmers.
- And, of course, it ignores whether these languages may be more productive to work in.
I agree with your first point, with one caveat: Only good developers try to learn new languages enough to get good at it.
At the price of arrogance, the "Average" developer in the "Average" company is pretty bad at developing. The experience I've had is that learning things is usually a good indicator of the love for doing things well.
The people who write crap code tend to also be the ones who don't even want to learn new languages, let along et good at doing so.
This argument isn't even internally consistent, let along based on good predicates.
He states that the better languages are the ones being learned. Then shows that Scala is the most popular language to learn ATM.
He then states that you should use a language with lots of popularity, which he also shows to be Scala.
Then dismisses it because there aren't many other companies using it, or developers who know it. Well, no shit: They're all busy using it and starting their own companies that aren't yet big enough to hire!
I have a bias that states that people who use github, hackernews and learn new languages are better developers in general because they give a shit about their profession. By this articles hypothesis, those people are worth exactly the same as any other developer, when we KNOW that a good developer is a MUCH better developer then an average one.
31 comments
[ 3.1 ms ] story [ 93.0 ms ] threadBelow are the figures I get (at this point in time) for the top two sets of figures provided in the post:
indeed.com:
linkedin.com:I will continue to choose languages that I enjoy and will continue to recruit people who also enjoy the challenge of learning new things.
Sure, a new hire may not have any Scala/Ruby/Erlang experience, but if they understand about source control (you'd be surprised!), testing, enterprise patterns and how to solve a God-damned problem, that's all that is important.
Important to what?
When starting a company, I think it's perfectly reasonable to worry about how easy it is to find people who know how to use your tools already. Sure, you can always train new people, but it takes time. In a new company, time is usually against you.
Not to mention, you want a good ecosystem for your tools, so you can leverage other people's work.
Sure, being exposed to a new set of languages and tools can have some start-up penalty. But if it takes someone more than a few weeks (< 3) to be good at Scala, Ruby, Python, etc then there is something wrong. Running through a complete tutorial and solving real problems on a real codebase over a couple of weeks should be more than enough time to become proficient with a specific language if you already have the skills of being able to problem-solve.
Don't confuse choice in your ecosystem of tools for quality. Just because there are tens of thousands of libraries for Java and .Net doesn't mean they are all good or that you can automatically choose the good ones.
The beauty of a more recently popular languages is that smart people tend to be attracted to them and, in my experience, they tend to create better quality libraries and tools, even though they are less of them.
Especially since ITA is still working on RES. Which is only "1/3" Common Lisp (web based front end is Java centric, back end is Oracle RAC, stateless middleware is mostly but not entirely Lisp).
I once worked at place that had a, relatively small, code base that contained more or less equal parts tcl, C, Lisp, Visual Basic, C++, Perl and probably something I'm forgetting due to the fact that the programmers got to choose their languages without any sort of supervision. It was no fun at all for anyone to work with.
"I'm Just A Recruiter With An Opinion"
Sorry, in my experience the opinions of recruiters on anything like choice of programming languages is probably worse than useless.
Really bad advice in the article here. There might be a few cases where the prevalence of a language/availability of help (assuming the language is non-proprietary and has more than a handful of users) might matter significantly (almost always to cater to the demands of individuals misinformed in a manner similar to the author of this article), but for a software project that you intend on maintaining, you should definitely pick a language on its technical and communal merits, and not the skills listed on LinkedIn.
I don't see a problem with pointing out that this guy speaks from the outside looking in.
Incidentally, I did co-found a start-up in '94 where we chose Java as the platform because we wanted to to do shrink-wrapped server side applications. Java was probably a lot less popular then than Scala is now and that choice turned out to be a huge advantage for us technically. I don't think any of first round of developers we hired had any real Java experience - it really wasn't a problem.
148,296 jobs (#1)
Here are some other questions the recruiter should have asked:
1. Can you develop your application less time using Closure or Scala than Java? How much less time? Can you iterate faster and try out more ideas before you run out of money?
2. How easy it to recruit good programmers who know Java? In my experience, less than 5% of people who apply for programming jobs know how to reverse a singly-linked list. In a startup, you care about the ease of recruiting 10x programmers, not the ease of recruiting warm bodies.
In short, the article explores half the problem. Without exploring the other half, there's no way to decide which companies should follow this advice, and which should contemptuously ignore it.
Grokking that goes a long way towards understanding this kind of blind decision making.
But is this an appropriate strategy for a startup? As Paul Graham points out, the average startup fails, so you don't want merely average performance. If you're not prepared to manage risky tradeoffs, you may not be prepared to manage a startup.
No. A startup should just use whatever the tech co-founder is going to work fastest in.
Hiring strategies shouldn't even be a consideration for a startup.
I don't know nearly enough Scala myself to have a proper opinion on this. From trying out Scala, I remember some features that seem highly dubious to me from a maintainability/readability point of view. In particular implicits and right-binding operators ending in ':' did seem to be asking for trouble, to a lesser degree the sometimes overly punctuation-based syntax ("\:" is the method name of fold left...).
I hope the op recognizes that organizations are inherently islands and sometimes the smaller more productive ones tend to be little paradises of productivity with no ferry service. Happy swimming there :-)
If I was assembling a team of Java programmers today, I'd prefer to hire an excellent Python developer than an average Java developer * . A great programmer can learn a language faster than an average programmer can become a great programmer. The great programmer could be reasonably productive with Java after two weeks, but an average programmer is unlikely to improve their problem solving skills, or their ability to cleanly structure large programs after the same period of time.
* Feel free to replace 'Java' and 'Python' with any two languages within the same paradigm. I don't mean to pick on Java as a language.
2) In the article he's ignoring many advantages that smaller languages have going for them:
- Much, much higher signal-to-noise ratio when hiring: The people who currently know Scala or Haskell learnt it because they love to program – they sure as hell didn't learn them to land a job. You can't say the same about Java, C# or PHP.
- You may make your company more attractive to the best developers: A company advertising for work in Java sounds very average (and a place to work for pointy-haired bosses). It will have to work a lot harder to stand out from the crowd. A company sounds interesting if it uses interesting languages.
- Great programmers will usually prefer to work with languages they are passionate about.
- Great programmers like working with other great programmers. I can assume I'm working with better programmers when joining a Scala team than a Java team. When hiring, you have to work harder to convince me you're good if you are a Java team.
- If you only hire great programmers, you can have smaller teams: ie, you don't actually need to hire as many programmers.
- And, of course, it ignores whether these languages may be more productive to work in.
At the price of arrogance, the "Average" developer in the "Average" company is pretty bad at developing. The experience I've had is that learning things is usually a good indicator of the love for doing things well.
The people who write crap code tend to also be the ones who don't even want to learn new languages, let along et good at doing so.
He states that the better languages are the ones being learned. Then shows that Scala is the most popular language to learn ATM.
He then states that you should use a language with lots of popularity, which he also shows to be Scala.
Then dismisses it because there aren't many other companies using it, or developers who know it. Well, no shit: They're all busy using it and starting their own companies that aren't yet big enough to hire!
I have a bias that states that people who use github, hackernews and learn new languages are better developers in general because they give a shit about their profession. By this articles hypothesis, those people are worth exactly the same as any other developer, when we KNOW that a good developer is a MUCH better developer then an average one.