Be Careful Who You Hire, I Know What Their Code Looks Like.

Written by on Aug 31 2007

I am going to start posting little quips our guys innocently say to me.

The newest member of the team sent me an IM today while looking at an application we inherited from someone else:

“I’m guessing this guy built the domain model correctly and then decided to mess it up later?” Be careful who you hire, there is a lot of bad rails code out there. Here are a few tips:

  • Don’t hire anyone who has never done a rails app before. Rails, although really easy to learn, is really tricky to “get right.” There really is a Rails Way to do things. Everyone’s first rails app is throw away code. Even mine was.
  • Don’t hire anyone who has only done one rails app. Are you getting the picture?
  • Don’t hire anyone who has only done rails apps that are for “internal corporate use only” and you can’t view them.
  • Don’t hire anyone who hasn’t blogged at least one rails tip.
  • Don’t hire anyone if you are not able to asses their technical qualifications. (More on this bellow.)
  • Don’t hire anyone who says, “I’ve never done a rails app before, but I’ve been doing (Java/.NET/PHP/etc) for ten years, so it should be no problem.” They’re wrong. Their first rails app will be throw away code.
  • Don’t hire anyone who will make an “admins” directory. Just ask them, they know what it means and they’ll either say yes or no.
  • Don’t hire anyone who spells assess with one S or spells below with two Ls.

I will add to this list periodically.

So I know what you’re thinking, either “But Steve, we’ve already hired someone, what do we do?” or “OK Steve, how do I find the right candidate?” 

Here are the answers:

If you’ve already hired someone and you have a sinking feeling (like the boat you’re on starts with “ti” and ends with “tanic,” or just want a sanity check, give us a call. We offer three free hours of code review. That should be enough time to get a feel for the quality of the code.

If you are looking to hire someone, we do offer an interview service. It is not free (in fact it’s a bit expensive), but it might be the right start for your project.

5 Comments

Chris
Chris said on August 31, 2007

As a .net guy getting into rails I agree with #6. I, and most of my employers, would say I am one of the best web guys they have had .net or otherwise and I am writing rails code but the level of quality is more of a prototype. This is because the code is very flexible but the framework is very opinionated so until you get in that groove happy prototyping.

molly
molly said on August 31, 2007

This was quite an entertaining bit. I remember when we started doing .NET ….looking back at the code is such a funny thing.

Anything you just started doing now… take a look at 1 year from now and you’ll want to scream,“What was I thinking?!”.

David Wilkins
David Wilkins said on September 05, 2007

Rails is moving fast, new ideas are being incorporated into the mainstream quickly. If you’re not comfortable with the current state of Rails, you’ll not know why the latest enhancement (REST, rspec, etc) is so important.

While talking to a guy from Joyent in the airport a couple of months ago, he referred to non-RESTful code as “legacy Rails” code. All Web development benefits from a measure of “staying abreast”, but Rails requires it. If you’re not willing to question almost everything, test and refactor like a ninja, Rails development will be painful.

I agree with the first app being throw-away. I think that any Rails app that’s been sitting around (read: not being maintained) for 6 months will contain a healthy measure of code that’s ripe for refactoring.

However, once that initial Rails app is under your belt, lots of the techniques (DB especially) learned elsewhere will help out with Rails. (i.e., never use now() or functions in general in a where clause, validate on the client and the server, premature optimization is the root of all evil, etc)

dhw

Raimond Garcia
Raimond Garcia said on October 03, 2007

Hi, I agree with all your points except for the one about the admin directory. It depends on the project, the best way to do it is to add edit, delete and new links to the website that the public can see only when an admin has logged in, like Ryan Bates explains in one of his railscasts. However in some cases you have many more models than what is shown in the public site, so you do need an admin console to add/edit/delete content. For this last scenario an admin directory with controllers for all the models is a great way to go, as you can separate the basic crud operations of the main controllers from other admin methods that are only available in the admin controllers, but in both cases you use the same models. I know what you are thinking, the CRUD operations are redundant, yes but its better structured and you reduce redundancy in other areas, like layouts and authentification, furthermore you can use a plugin such as makeresource which gives you all the CRUD operations with one line of code in your controller.

Check out DHH’s Keynotes in RailsConf Europe 2007 about admin sections in your app. This is some code he showed

./script/generate controller posts # => /controllers/postscontroller.rb
./script/generate controller admin::posts # => /controllers/admin/posts_controller.rb

http://casperfabricius.com/blog/2007/09/18/railsconf2007-dhh/

Regards,

Raimond Garcia

Steven A Bristol
Steven A Bristol said on October 03, 2007

Raimond,

Now that Rails 2.0 is embracing namespaced routes, I agree that it is finally OK to have an admins directory. I still think that for a pre 2.0 rails app, it is not OK. So the interview question becomes “Did you have an admins directory before 2.0?”

Meet
Steven

Hi I'm Steven,

I wrote the article you're reading... I lead the developers, write music, used to race motorcycles, and help clients find the right features to build on their product.

Get Blog Updates