In light of RailsConf last month, I spent some time thinking about my experience learning Ruby and Rails back in 2009. The conference included quite a few seasoned veterans, but like any popular technology, there was also plenty of people that either just started learning Rails, or are considering doing so in the near future.

Turning the clocks back to when you knew much less about something is hard. But putting yourself back in that position can offer valuable insight to the opportunities available and how they might be improved in the future.

How I Started

Most come to the Rails community not knowing much about Ruby. Learning any new technology is hard. And learning a few at the same time is even harder.

This was me in 2009. A relatively new Rails 2.3 app was dropped in to my lap, and despite only having experience with PHP, my job was to aggressively ship new features. I read Agile Web Development with Rails cover to cover and dove in head first. Little did I know it would be one of the best career decisions of my life.

I spent the next few months pounding my head against my desk. The days and weeks of frustration seemed endless. And then…it just went away. The pain I’d endured merged in to an intense desire to dig in harder. There were more light bulbs moments in the months that followed than any other time I can remember.

During those intense months of frustration, I leaned heavily on the Rails and Philly.rb IRC rooms. In the former, I tried not to say anything too stupid. Fortunately, the latter felt more welcoming and approachable and I owe that group a lot of holding my hand through what might have otherwise been a deathwish for me and the Ruby language.

A few questions pop out in my head…I was confused about filtering an ActiveRecord query and was surprised to learn methods that were built in to the Ruby language would do exactly what I want. At the time, if it wasn’t in ActiveRecord, it might as well have not existed to me.

From someone who advocates for using tools without fancy DSL’s, this is hysterical to me. Ruby, of all things, had the answer. At that point, I’m almost certain I’d never seen the Ruby standard library documentation.

Rails Starts Where Ruby Stops

Out of convenience, Rails does a lot to make our experience with the Ruby language easier than it is out of the box. Like 2.hours.ago….none of this is possible if Rails doesn’t monkey patch the Integer class. For someone who doesn’t know any better (me in 2009!), being able to calls #hours on an integer just seems like something the language would do. Because Ruby was created for developer happiness, right?

So perhaps the approach of monkey patching doesn’t offer a clear indication of where functionality is coming from. The flip side of that argument is convenience. If I had to instantiate a time-related class every time I wanted “noon time yesterday”, maybe I’d be slightly less enthralled with my ability to get stuff done in Rails. Perhaps it would cater more to the true OO neckbeards, but also may have resulted in far less adoption. Who knows!

I don’t have strong numbers to back this up, but I’m guessing large majority of developers that get paid to write Ruby, due so within the context of a Rails application. And whether we want to admit it or not, a large reason new developers learn Ruby, is to learn Rails. So does it matter that newcomers don’t know Ruby?

From the standpoint of creating a web application fast and being able to iterate quickly, maybe not. But certainly if the person is interested in understanding the interworkings of what’s happening within the application, knowing where Ruby stops and Rails starts is ideal.

How to Start?

I’ve talked to quite a few people that are new to Ruby and I always struggle to suggest a good start project when they ask. Everyone learns differently and has different interests, but in general, I think there are core-level motivating factors that can keep someone focused and interested.

To me, it’s the following:

1. Does the project have real-world value?
2. Does the project offer immediate feedback?

Why does it matter if the project has real-world value? For one, continuing on something that doesn’t improve our lives is sometimes hard to keep up with. And learning Ruby/Rails is definitely something that’ll take more than a few nights and weekends. If the project we’re driving towards continues to seem desirable, we’ll have a better chance not to lose focus.

Second, I don’t want to get too philosophical, but there are plenty of resources that suggest if you want something badly enough and can visualize the end goal, there’s a higher likelyhood that it’ll come to be. Our desires will be stronger when we can see the end goal and know there is an increased real-world value for this application to be in existence.

The immediate feedback piece shortens the time we’re able to see changes and progress. This brings a lower rate of abandonment and better chance we’ll see the project through.

Rails answers both of these questions with a resounding, “YES!”. Think about it…

Does a Rails application have real world value? Of course it does. It’s a web application. There has been no better time to be focused on Rails, where it be for the web and the backend of a mobile app.

Does the project offer immediate feedback? Sure does! A couple keystrokes and a refresh can give you instant gratifcation in the browser (or the occasional disappointment!).

Whether it’s a command-line tool, game, or other utility, I struggle to find other oppotunities to get people started. Frankly, many newcomers to Rails have never used a terminal before. So why would we suggest a command-line application as a good place to start? This is especially true for someone with little programming experience.

For the experienced developer, it’d be much easier to suggest writing something like a markdown processor, but only because they have the context of another language. At that point, they’re really just comparing the Ruby language to what they already know and figuring out how to translate the things they do know to Ruby.

For a new developer altogether, they would get little value of writing a markdown processor, and in fact, probably seems more like a research project than a sure-fire way to learn a developer-friendly programming language.

So now we’re back to suggesting Rails, but then you consider everything else a newcomer would need familiarity with to traverse the Rails eco-stytem: HTML, CSS, Javascript, Coffeescript, Sass, SQL…

The list goes on and on. Not so easy after all. No wonder people get intimidated and bail. I suppose there’s starting with Sinatra, but the doesn’t remove you from the HTML and CSS requirements. Perhaps those impossible to dodge, given the medium. And even with Sinatra, we often end up creating the functionality that’s in Rails anyway.

I wish I had a better answer.

How would you suggest someone start with Ruby?