Learning Rails vs. Learning to be a Rails Developer

evolutionA little over a year ago I started on my first Rails app.  I’ve been off in the business world for the past 10 years, and have been itching to get back into application development of some kind again.  Some of my still developer friends had been talking about Rails and it sounded really interesting, so I thought I’d make that the focus of my first development side project.

I had an idea I wanted to implement, and searched around for some sort of Rails documentation or tutorial.  In a short period of time I found Michael Hartl’s Rails tutorial and dug in.  What an awesome resource!  I mean, Rails is pretty complex, and takes care of a lot, and I didn’t know any Ruby yet… but my first night working on the tutorial I had something really basic working, and I was hooked.  The nomenclature was weird, I didn’t understand the makeup of the whole stack, and a lot of times things seems to work magically and fail mysteriously, but but I got enough positive feedback I knew I could get better.

After a couple of months I had the initial version of Wikiometer up and running, and my family and friends had tried it out.  It was a really good feeling to have created something again… and I wanted to do more, and get better at it. So I dug into the community resources… and was amazed.  There was / is so much happening in the Rails space, and the community is generally so helpful and respectful.

As a relative latecomer to the community I didn’t know all the history and politics about different ideas.  It was confusing to read one tutorial where the author used Rspec, and another where another author used MiniTest.  What’s the difference?  Why is one better?  I couldn’t find any clear information.  I had heard of unit testing before, but not TDD… How do you do it right? What do you test?  How do you know you’re doing it right?

And these are just a couple of examples.  For illustration, other technologies / concepts I ran into pretty quickly that were confusing were: SASS, HAML, coffescript, JQuery, Reddis, Capistrano, Vagrant, Chef, Puppet, Git, CSS frameworks, Responsive Design, OOP, Service Objects, Design Patterns, Law of Demeter, Functional programming, VIM and associated Rails / Ruby plugins…

Looking back, I’m recognizing that much of the confusion I felt as a total novice is because the Rails community is evolving.  For example, on the Rogues’ Parley mailing list there has been recent discussion about the right ways to use git, both to maintain s meaningful history, and also to minimize noise in the history…

And I’m realizing there is a lot of personal opinion in the Right Way to do things.  Even in the OOP vs. non-OOP design is a debate.  On the one hand the reasons for developing OOP code for Rails apps make a lot of sense, but on the other hand, taken too far one can imagine things devolving to a Java like state that really wasn’t that fun to develop in… And it’s all about fun right?

After a little over a year of part-time coding and part-time learning, it feels like becoming a full-stack Rails developer is a life-long pursuit. The underlying and adjacent technologies are constantly evolving, both Ruby and Rails are still changing, and things like coffescript, SASS, and HAML wax and wane in importance depending on the development team I work with.  In the end, to me, being a good Rails developer is about staying curious and continually learning how to be a better Rails developer, from knowing my editor, to writing more effective code with less effort.

Leave a Reply

Your email address will not be published. Required fields are marked *