Houston, we have a problem.

If you’re a Rails developer these days, chances are your career is going well. You’re sitting pretty, secure in your knowledge that should something happen with your current gig, you’ve got a better-than-average shot at finding employment within a couple of weeks, at least if you’re in any city large enough to support an employer that hires a lot of developers. And if you’re not, there’s lots of freelancer gigs open that allow telecommuting. In short, its a good time to know Rails.

Rails is probably the fastest-growing platform in use on the web today, with good reason. For a seasoned developer who follows Agile methods and uses test- or behavior-driven development in some form, it distills the best practices of 15 years of dynamic web development design principles into an accessible platform. It allows us to code quickly and more efficiently than any other solution out there, and as a result our productivity skyrockets. Ruby is a pleasure to work in (in fact, that’s one of its primary goals.) Its popularity has led it to become far more accepted in the corporate world than it was just two years ago. Considering these factors, it should come as no surprise that Ruby hiring is up. (The numbers fluctuate day to day, but if you look at the trend over the last year there’s a marked upward trend in Ruby jobs.)

It seems like we, as Rails developers, ought to be pretty happy about this situation.

So what’s the problem?

Anybody who’s attempted to hire a strong Rails developer in the last year or so (in most of the country, anyway) has probably asked themselves the following question at some point: Where the hell are these guys hiding?

The reason its so easy to find work is that there are so few qualified Rails developers to fill the positions. By qualified I mean that they are knowledgeable about the community’s best practices, that they’re fairly knowledgeable about the gems and plugins available in the ecosystem, and that they not only know how to write tests but that they do so almost obsessively. Unfortunately most new Rails developers find themselves struggling with the most basic design patterns in Ruby, coming from languages where those patterns are either not widely used or not adhered to effectively. For example, many PHP-to-Rails conversions, at least at some point, start out writing views incorporate a lot of logic that ought to be in the controller or a presenter. This is a common design pattern in PHP, and one can forgive the neophyte Rails developer for trying to translate their existing knowledge directly over to the Ruby on Rails world.

Testing is another area that new Rails developers struggle with. In most other languages, especially those that target the web, testing is an afterthought. Most languages make it fairly easy to do unit tests, but getting into functional and integration tests is progressively harder and more time-consuming, so they tend to get dropped. When these developers come over to the Rails world, testing is invariably the chapter of the book that gets relegated to “I’ll learn this later.” The problem is so bad that in my personal experience, the single determining factor in whether a Rails developer is hirable is whether they have a handle on testing. If they know how to test, chances are they’ve done real work in Rails. If they don’t, they probably worked on a side project or three to teach themselves the platform, working without the benefit of real mentorship.

Get to the point!

Bottom line: the Rails employment community is not a healthy ecosystem. There are far too many open jobs and far too few Rails developers to fill them. What happens in this situation? Eventually employers who want to start Rails projects decide that its really not worth the effort and decide to use some other platform for their next big idea. Supply and Demand—its a bitch. When supply is constrained it works out well for the suppliers for awhile, at least until demand is satisfied through some other means. “Some other means” in this case means some other platform: Java, PHP, the Next Big Thing™. Anything that’s an easier platform to find developers. I’ve talked to a few recruiters in the last few weeks, all of whom are saying the same thing: this employment situation is unsustainable in the long-term. A couple have had clients who decided to rethink their project plans in light of the hiring difficulties they’re having. This is the last thing we need right now, given the state of the economy.

Fix the problem.

As a community, we have to fix this. If we don’t, most of us will find ourselves back in the position we were in a few years ago, when finding work in our favorite platform was all but impossible. We’ll probably be worse off, since many of us will be without recent experience in more well-established platforms.

What steps can we take to fix the situation? At a basic level, we have to foster a mentorship mentality within the Rails community. Like most new Rails developers, when I was starting out I had no idea how to test well. It wasn’t until I started working closely with other Rails developers who knew how to test that I started to “get it”. [Full disclosure: I now work for the guys that helped me along.] We need this kind of mentorship available to new Rails developers to turn them into employable assets within the community and start plugging the gaping hole in the job market. New Rails developers have to work harder at reaching out to the resources that are available in the community.

In my own community here in Austin, I’m going to be embarking on a little experiment this fall. The plans are still hazy at this point, but the gist is that starting in early September or October at the latest, I want to begin a four-week series of classes on Behavior Driven Development, with the goal of turning new Rails developers into more medium-level, employable Rails developers. The ideal student will be someone who knows Rails—maybe you’ve done a couple projects in it and really skipped out on the testing, or maybe you know just enough to be dangerous. Maybe you’ve even done some testing but its been mostly unit-level. My plan is to teach cucumber and rspec, and maybe bring in another instructor or two. There probably be some nominal fee to cover the cost of the venue, but it won’t be much.

Class time is great, but students also need practical time working with these ideas, so I want to include some lab time, and I’m hoping to hijack leverage Damon Clinkscales’ Cafe Bedouins group to provide a forum for experienced Rails developers to come in and pair up with more junior developers and provide the direct mentorship that I think can transform a junior developer into a mid-level, employable developer.

If this effort goes well, we’ll likely release the materials under a CC license and try to replicate the effort in other cities, as well as teach a similar bootcamp on Rails itself to keep the ecosystem thriving.

Shameless plug

Under our Idea Foundry brand, we teach this material in both public and private classes. We’re looking at planning a slate of classes in the Austin area, so if you’re interested in learning more or finding out when we bring one to the area, fill out our Interest form. We’re also available for one-on-one mentorship services for both companies and individuals looking for something to really help them along.



  1. July 12, 2010 at 9:04 AM

    Keith, how often do new clients come to you because they want a Rails project, or because, they want a web based application?

    I have felt the lack of Rails developers in trying to find someone to help me with the overflow of work I have.  I have thought “is there a Rails developer out there who isn’t booked for the next month?”  It has lead me to begin training the high school kid I hired to do Harmony websites, to do Rails apps.

    I agree that it will benefit the community as a whole if there are more “qualified” Rails developers.  I also have this hope that it’s not about the platform, so much as the service offered.

    Thanks for the post!

    Also I highly recommend one-on-one mentorship to anyone looking to take next step.

  2. July 12, 2010 at 16:35 PM

    Torey Heinz: At least in my time with Collective Idea I think its fairly common for a client to approach us about a new project that they want done in Rails, rather than approaching us about an idea for which they haven’t chosen a platform. Typically someone they know and trust has recommended they pursue a Rails strategy, or they have it in mind for some other reason. Ultimately I think our clients are deciding on Rails because it offers dramatic productivity gains, but since the decision is usually made by the time they get to us I don’t know for certain. I think part of the reason for that is that I don’t think we heavily market ourselves to a more general web development audience.

  3. August 18, 2010 at 12:48 PM

    Interesting post.

    I cannot agree more on the lack of good Rails coders out there. When potential clients come to me for design and say they want their app coded in Rails, the first thing I tell them is that unless they have an experienced, reputable Rails coder lined up, they should think about looking at other frameworks (actually, why non-coders want their app to be in any particular framework is another discussion, but I digress).

    As far as learning Rails goes, as a somewhat-technical designer, I can say Rails is one of the most noob-unfriendly frameworks around. Not because Rails is intrinsically harder than other frameworks, but because it is the most backwards-incompatible framework I have ever seen! Almost no tutorial or book out there will be valid 3 months after it is written because of changes made to Rails. Experienced Rails developers have a hard time porting their apps when every new version of Rails is released; noobs have no hope of figuring out which part of the tutorial/book they are using is causing their code to break. That’s another reason why Rails mentors are so important; for better or worse, keeping up with Rails is really a full-time gig :)