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.

Advanced Rails Recipes

I loved Rails Recipes, so when Mike Clark and Chad Fowler asked me to contribute to Advanced Rails Recipes I was quite excited about the opportunity. My contribution to the book was a write up of the Presenter Pattern. Advanced Rails Recipes is now available as a beta book at pragprog.com.

When not to pair

Last night, while talking with Mike Roberts and Martin Fowler the topic of Pair Programming came up. We are all proponents of Pair Programming, but inevitably the question came up concerning when Pair Programming isn't recommended. I've always liked the suggestion that any activity that requires an artist can be done more accurately/effectively while pairing.

It's not uncommon to hear that developing software is an art. This is a general statement that is often true, but it's the tasks that don't require an artist that I believe can be done without pairing. What tasks don't require an artist? I would say any task that has only one right answer. For example, the task "Table Users needs an index on the Login column" likely only has one correct implementation. Adding an index can be done a few different ways, but I expect a project has a convention on altering tables and adding the index in that way is the correct execution of the task.

I do believe tasks that have only one correct answer can be done without a pair, the tricky bit is finding tasks that have only one correct answer.

Utilizing Ruby and Linux

I've recently been working on a site that aggregates a large amount of data. The data is made available at arbitrary times and delivered via xml feeds over the web. I needed to check for new content at timed intervals and I needed a mechanism for delivering a large amount of data quickly.

The first problem was easily solved by writing a ruby script that checks all the sources for new content and setting up cron to run the script every 15 minutes.

Making large amounts of data quickly available was solved by using Rails page caching, but the first request was still taking about a minute to serve. That issue was also easily solved by sending a curl request after each time the cache is swept.

One of the reasons that I love working with Ruby/Rails* is that not only do I have all the tools Ruby provides, but I also have easy access to the tools available on linux.

Next time someone asks me why I like Ruby more than other languages, I'll have to remember to add this to the list of reasons.

*Most languages give access to the underlying OS, but I find Ruby's access to Linux to be more pleasurable than other experiences in my past.

ThoughtWorks DSL Podcast

I recently participated in a podcast with Martin Fowler, Rebecca Parsons and Neal Ford on the topic of Domain Specific Languages. The podcast is being released as part of the ThoughtWorks IT Matters series and is available at ThoughtWorks: What we say.

Feedback welcome.