True, But Useless Information

by Krishna on May 1, 2011

From an old article by Paul Graham:

In a recent talk I said […] that you could get smarter programmers to work on a Python project than you could to work on a Java project. […] I meant that Python programmers are smart. It’s a lot of work to learn a new programming language. And people don’t learn Python because it will get them a job; they learn it because they genuinely like to program and aren’t satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I’ll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they’ll be able to hire better programmers, because they’ll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don’t learn merely to get a job.

The average Python programmer being better than the corresponding Java programmer seems true to me (even if Python is not particularly hard). And today, you could probably add languages like Ruby or F# to the list. The less mainstream the language is, the more knowledgeable someone is in that, the more likely that they are a better programmer and interested in programming beyond a paycheck.

On the other hand, this is almost worthless as a criterion for improving your hiring and selecting your company’s technology. Your biggest problem as an employer, especially if you are a small company or a startup, is to find capable individuals willing to throw in their lot in with you, instead of working at a larger company such as Google or Facebook where they could work on complex tasks and have better job security at the same time. You are looking for talented programmers who are willing to take risks with a smaller company. And at any point in time, most good programmers are not looking for a change.

In any case, your choice of technology and language should be determined by what is best for your product and the skills of your existing employees, not the capability of a future employee. What language and framework will help you deliver the necessary features faster? Which is the strength of your present team? If you need to choose a technology that the existing team members don’t know, how much time would it take for them to master it? What friction in development would you experience in making the change?

Being able to hire the next programmer belongs to the category of problems called “high-class problems”. They are problems of success rather than failure, and they can usually be fixed or mitigated by spending more money. But to achieve success, you need to focus on the here-now, and the choice of technology should be determined by the current factors, not something you would find it easier to do in the future.


Agile Scout May 1, 2011 at 10:37 pm

But then... oh then... what happens when code languages ... that were obscure... become more popular?
The cycle continues?

Krishna May 2, 2011 at 10:51 am

There doesn't seem to be any lack of innovation in the programming language space. The better programmers keep moving up the scale, either with newer programming languages, or better/more complex features in existing languages, new pgmg techniques and so on.

Comments on this entry are closed.

Previous post:

Next post: