Sunday, December 09, 2007

Is being a niche language developer good for your career?

Paul Graham originally introduced me to the idea that programming in a niche language was a good idea. He makes great arguments for organizations adopting more powerful languages and hiring smaller teams of highly effective programmers that can harness the power of niche languages. Paul Graham made me feel good about working exclusively on Ruby projects.

Later I read (the fantastic) My Job Went to India by Chad Fowler. Chad also talks about how being proficient in a niche language can make you a more valuable asset. Again, I felt good about focusing so heavily on Ruby.

February marks 2 years of nothing but Ruby projects. I'm still happy with the decision, but choosing Ruby has certainly brought unexpected consequences. I've gained an enormous amount from my recent experience; however, this entry serves to highlight the sacrifices that are required when focusing on a niche language.

One undeniable drawback to focusing on a niche language is that your employer choice becomes severely limited. For example, there are Ruby jobs available in New York City; however, I only know of one organization in the entire city that would be a good fit for me personally if I decided to leave ThoughtWorks*. NYC isn't exactly small either, if I moved to a smaller town the chances are even higher that I would have a hard time finding an employer with values similar to mine and still be able to make a living as a Ruby programmer.

A great lesson from My Job Went to India is that you should strive to be the worst member of a band. If you haven't read the book (read it soon!), the lesson is essentially that you perform at a higher level when you work with others who are performing at a higher level. I agree with Chad's advice; however, it's harder to be the worst member of a band if there are limited numbers of musicians you can work with. Some of the greatest programmers I know are getting paid to deliver Ruby applications, but I still know significantly more great developers who are not. Sadly, when focusing on a niche language there are simply fewer mentors available to learn from.

Another constant pain point for niche languages is the lack of respect that they are given. In the enterprise world, Ruby is largely seen as a toy. As a result, Ruby programmers are seen as "hackers, script kiddies, immature and uneducated." I do believe this to be far from the truth, but that doesn't change the fact that it is the general attitude. This leads to unfriendly treatment at conferences, and worse it can also cause an interviewer to unfairly discredit a qualified candidate.

Niche languages also suffer from greater prejudice. No matter how many success stories emerge, it's still very common to hear that "Ruby doesn't scale, just look at Twitter". There's very little truth in the statement, and yet it still follows Ruby every where Ruby goes. Niche languages simply have more detractors and thus the propaganda emitted by the detractors reaches larger audiences.

Adoption leads to patterns and best practices. Obviously, greater adoption can lead to larger amounts patterns and best practices and lower adoption rates have less to offer in the way of established ideas. While developing an application with a niche language, it's not uncommon to be the first person to tackle a new problem. Blazing a new trail is often exciting, but it's rarely as efficient as following a proven path.

Vendor support is also often limited for niche languages. My first 3 Ruby projects were backed by an Oracle database. At the time, the Oracle driver for Ruby on Rails wasn't exactly what I'd consider to be stable. The driver has improved, but using Oracle is still a pain to this day. Currently, TextMate is the #1 choice for developers writing Ruby on Rails applications. TextMate runs exclusively on the Mac. Oracle not only does not run on (Intel) Macs, but doesn't even offer a (reasonable) way to connect to an Oracle database from a Mac. Therefore, it's (basically) impossible to run TextMate and connect to an Oracle database from the same computer.

To be clear, I'm very, very happy with my decision and the past 2 years of projects. I won't bother with writing up the merits of adopting a niche language, see Chad Fowler and Paul Graham's work for that. However, I do think it's important to note that adopting a niche language can carry some unfortunate consequences.

*I'm not leaving ThoughtWorks. I'm very happy at ThoughtWorks.


  1. Nice post.

    ... You can always use JRuby to at least connect to an Oracle database. =)

  2. You can also use Ruby in PowerPC emulation mode to connect to Oracle database using Oracle Instant Client. See this description.

  3. Anonymous7:58 PM

    For accessing Oracle:

    SQL Relay is ideal for:
    # accessing databases from unsupported platforms

  4. I am going to comment on Oracle like everyone else. I see the problem being solved two ways, but coming to the logic of finding the right tool for the job. Either use JRuby as suggested or switch to another language that has Oracle support. You give no reason to why Ruby is solely used for all your projects. Just off the top of my head (and personal preference) Perl DBI.

  5. Anonymous11:29 PM

    Am I missing something?

    Why would you insist on using a language/platform that is not a good fit for the job?

  6. Anonymous11:48 PM

    I work primarily with Oracle on my Mac at work... try (my preference) or .

  7. Anonymous: Just because a framework comes with perfect support for one particular integration point doesn't make it the best tool for the job. A framework that comes with perfect support for every integration point may still not be the best tool for the job. Likewise, imperfect Oracle support hardly disqualifies Rails from that position.

    The best tool for the job is the one that fits the needs of that project best. If your project circa 2005 requires that you integrate tightly with Oracle, and in particular that you require advanced features of Oracle, and if that integration is so important as to nullify the accessory benefits you gain simply from using Rails, then yes--Rails is no longer the best tool for the job. But we don't have enough information to make that judgment here.

  8. Anonymous2:09 AM

    I had a friend who said "I need a job." I replied, "Why limit yourself, say 'I need an income'."

    95% make 5% of the money, so own it.

    Be 5% and make 95%.

    Even if you're not creative, surely you have friends. Use your ideas. Have fun. Make money. Make a Difference.

  9. My experience is that it makes getting a job harder, but makes the jobs you find more likely to be a fit.

    Also, I can't believe there are that few people using Ruby in New York City. I've seen at least 15 postings that I'd seriously consider here in Portland, there's got to be an order of magnitude more in NYC.

  10. I'm not a niche language developer, but I primarily focus on one PHP framework (CodeIgniter).

    I've found it has led to an enormous rise in not only the number of clients but the quality of clients as well.

    By establishing myself as a leader within this relatively small community, I pretty much get "first dibs" on any paying job that is presented to the community.

  11. I agree with you, even though working as a freelancer or running your own company would allow you to work with your language of choice when a new client approches you to build a project. Most of the times, at least in my experience, they don't care too much about the language you use as long as the project is delivered on time and the app runs smoothly.
    Unfortunately there doesn't seem to be much space for Ruby in enterprises, but hopefully things will change...

  12. Anonymous3:50 AM


    Why dont you solve your db access problems by going with JRuby. It solves your db access problem using jdbc and personally JRuby has come a long way and I consider it a viable platform for many applications today.


  13. Anonymous6:52 AM

    I use Textmate/Ruby/Oracle every day on my MacBook Pro.

    Simply split off a PPC-only binary of Ruby (as a previous commenter commented) and make sure everything else (Gems, etc) are universal binaries.

  14. Interestingly enough, the job I have now which primarily uses Ruby/Rails, hired me knowing I knew nothing of it. I was hired INTO the niche.

    This type of 'painting into a corner' can also happen with frameworks, particularly in the JavaScript realm.

    I preferred mootools, and still do, but the rest of the world seems to be stuck in a Prototype/jQuery world. Luckily the people I work with are open to new ideas, and frameworks.

    There's no doubt that you shouldn't focus on just one language, you might not be an expert in every one that you learn, but at least you'll leave open some outs if you ever need them.

  15. > As a result, Ruby programmers are seen as "hackers, script kiddies, immature and uneducated."

    I kind of like this. It means you don't have to play by their crap rules. If someone is bigoted enough not to offer you work because of this, you probably wouldn't have been happy working with them anyway.

  16. Anonymous3:35 PM

    Niche languages do not all lack a rich set of patterns, solutions and paths. Old languages become niche languages, and retain a heritage from having been very widely used: COBOL, FORTRAN and PL/I come immediately to mind. Still in use today, yet in a niche.

  17. Anonymous5:37 PM

    Regarding Oracle + Mac, I haven't worked with Oracle for over a year now, but next time I need to I will check out all the links. Thanks for the info.

    Regarding why I would use Ruby, as Brian already stated, there were other reasons why it made sense. The deployment environment was Linux so there was no blocking issue that stopped us from using Ruby. Despite the Oracle hurdle it was still a right choice for the problem we solved.

    Regarding getting work, it's quite easy to get contract work in niche languages; however, that's not the kind of work I'm looking for. There are also plenty of jobs that are better on average than the normal Java job, but as you get into the "great" jobs, there are simply way more to choose from when selecting a mainstream language.

  18. Can't we all just get along? You realize, of course, that ultimately this sort of discussion makes absolutely no sense to most of the users of your software. They don't care what it's written in, as long as it works.

    I program in the red-headed stepchild of Web App languages, and have made a nice little business out of it.

    I always get ridiculed when I speak its name, but the fact that it 1) works on anything that can run Java, 2) is simple to implement, 3) has a large developer community, 4) is what I have written my web app framework in (which works very well, thank you) are all ignored because it is not perceived as a 'real' language.

    Tell that to my customers. They love what I sell them, it makes their lives easier and they can get a spectacular feature set in weeks what would take months if written "the right way". That is all they care about.

    Now, would I like to learn some other tools and languages to broaden my capabilities? Sure, I'll get to that-- with all that spare time I have left over after all the projects I always seem to be working on.


Note: Only a member of this blog may post a comment.