How To Choose Programming Languages For Team Projects (Hint: Avoid Scala)
blog.captainrecruiter.com
blog.captainrecruiter.com
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'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.
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.
Below are the figures I get (at this point in time) for the top two sets of figures provided in the post:
indeed.com:
36,337 Perl (#3)
18,470 Python (#5)
126,992 Perl (#4)
68,630 Python (#5)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.
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).
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.
148,296 jobs (#1)
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 :-)
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.