Mike Clark

Code wants to be responsive to change, and when it doesn't get its way it tries to warn us. But often we aren't listening because it's too easy to plow ahead to the next feature. Unfortunately, in our haste we miss a golden opportunity to improve the code, which is actually the design. And although the consequence of ignoring the code isn't immediately noticeable, it quickly starts to drive up the cost of change.

In the latest installment of my Code Craft column, "Relocate for Reuse", we stop to listen to the code. Heeding its warnings, we find a new home for small methods that fell out of earlier refactorings, and end up with code that can be reused.

Let me start by saying that the information I'm about to describe is the result of programming for fun. I've been watching the uptick of Ruby and Rails job postings with keen interest as of late to see if it offers any insights into the future trends of Ruby and Rails. Clearly I'm sold on the value these technologies bring to the table, but are other projects also looking to cash in on the benefits of Ruby and Rails? And if so, what skills are they looking for, where are the projects based, and what kind of employment arrangement are they offering? I don't have all the answers yet, and likely never will, but that never stopped me before.

So I started by tuning my RSS reader in to Jobs.Rubynow.com and watching the first 30 Ruby/Rails jobs get posted. (It's a free site, so I figure there's no reason employers wouldn't post there.) The RSS feed would have been helpful if I was actually looking for a job. But I'm less interested in the details of a specific job posting (one data point) than I am in data aggregated across all postings (a potential trend).

Synthesizing all the postings into a summary report that tries to answer the aforementioned questions called for some automation. As new jobs are posted, I need to remix all the data. Now, I don't have direct access to the database used by Jobs.Rubynow.com, or any other site's database, so I have no choice but to resort to the world's greatest remote database access tool: screen scraping. That, a wee bit o' Ruby code, and an ERB template turns all the job postings into ten buckets of tokenized terms and the number of times each term was used in the postings. That's it. No statistical analysis. Simplest possible solution. I made no effort to get fancy other than to use regular expressions to ignore the HTML tags, white space, and some boring words such as the. Indeed, I wanted the data to be raw so that it's open to interpretation.

Have a look...

I think it's still too early in the game to spot trends, especially with such a small sample set. And rather than try to draw conclusions for you, I'm interested to hear if you find anything worth keeping an eye on. Does the fact that there are almost as many off-site (telecommuting) jobs as there are onsite jobs say anything about where we are in the adoption curve? How do you get a Ruby/Rails job if the top required and desired skills are related to experience with Ruby and/or Rails? Are you more likely to find a job if you have prior experience with Java, PHP, or both? What buzzwords aren't on your resume? Why do recruiters have such poor spelling skills?

And of course this data may be utterly meaningless. After all, the word management listed in the Required Skills section has zero subcontext. You don't know if they're looking for someone with an MBA or someone with experience driving a truck for waste management. I'm ok with that. Again, it was a fun little hack to write. I'll run it once in a while to see if anything compelling pops out. Or, better yet, perhaps the folks who run the job site will do it for us...