There are countless links out there that will bury you in suggestions for how to write Rails code, so I’m going to take the road less travelled and give you three non-code tips that I think are really important.

h3. Learn Some Ruby

I know this one is dangerously close to being a code tip, but I really mean this in the general sense.

Many programmers come to Rails directly, without prior knowledge of Ruby. That’s terrific! We don’t care how you get here, we’re just thrilled you found your way.

However, a lot of people don’t go much farther than that with Ruby itself. You can write a fair bit of Rails code without getting deep into the underlying language, but you really don’t know what you are missing.

I’m being 100% honest when I tell you that I’ve seen all of these things in Rails code:

1. Constructs that could be 30 lines shorter with trivial use of a block or a method_missing() definition.

2. Complicated buffering layers wrapped around services Ruby is already buffering.

3. Painful recreations of libraries that ship with Ruby.

4. Code that used each() when map() or inject() would have been a much better fit.

A little knowledge really goes a long way here. You will be surprised how much easier you fly through tasks and you will find endless fun in shrinking your application’s code base dramatically with the timely use of some Rubyism.

Luckily, if you are in this category of Ruby users, an excellent book was recently published just for you. Run, don’t walk, to purchase a copy of Ruby for Rails. I promise you won’t regret it!

Remember the YAGNI Principle

Luckily, Rails programmers seem to have a lot of great habits! Unit testing and agile development are very popular in Rails circles. DRY is a popular slogan for Rails programming too. I couldn’t be happier.

Since I probably don’t need to tell you to read up on those, I’ll pick a different good habit to promote: remember the YAGNI principle.

We all do this. I know I’m guilty, but I’m really trying to get better about keeping this in mind when I work.

I’ve worked on Rails applications where multiple features were explained to me as, “We’re going to need this down the road, so make sure you build this part carefully…” Red flag! That’s a no-no.

The problem is that you are guessing here. You are guessing that you may need this feature someday; you are guessing that you know how it will have to work; etc. Any one of these guesses could be wrong. In fact, it’s a very, very safe bet one is, just based on the law of averages.

When any one of them is wrong, you blew it. You complicated the current development, possibly even pushing aside needed or nice-to-have features, and you will still need to redevelop this code when the real requirements show up. You paid for this code a minimum of two times. That’s not a good trade.

Besides, you’re agile so you will have no trouble adding the feature when the time comes, right?

Get Involved!

I know this one is going to sound almost silly, but take it on faith if you must: join a Ruby/Rails community today!

I’ve learned a crazy amount of programming from books and classes, but I’ve learned at least twice that knowledge from interacting with other programmers, scout’s honor.

Whether you are teaching, learning, goofing off, or just spending time with your peers, it’s hard to avoid picking up the nuggets of wisdom from others. You will be amazed what even the beginners have to teach you with their fresh perspective.

Find an established group and attend their meetings. Budget time and money for conferences. Start a local user’s group if you have to. (You’ll learn at least as much that way!)

You share a common interest with a large body of people. Seek them out.