This post originated from an RSS feed registered with Ruby Buzz
by Christian Neukirchen.
Original Post: How Rails made me a better programmer
Feed Title: chris blogs: Ruby stuff
Feed URL: http://chneukirchen.org/blog/category/ruby.atom
Feed Description: a weblog by christian neukirchen - Ruby stuff
The question how Rails made me a better programmer can be answered in
a short, but incomplete and actually wrong way: It didn’t.
That is only half the truth. When Rails was released in 2004, I
already had almost three years of programming experience in Ruby.
Therefore, I don’t think I learned much from Rails in a technical way.
I knew MVC, the code didn’t particularly impress me, and, in the end, I
didn’t care a lot about web development either. At that time, at least.
The things I’ve learned (or everyone could learn) from Rails are
social lessons. Some of them were to be expected, some were very
unexpected and a few still make me question the universe everytime I
think of them.
So, what did I learn from Rails?
Community matters. The best idea is useless even in the literal
sense if nobody uses it. I did not learn that directly from Rails,
since Ruby had (and still has) a very nice, but at that time rather
small community. (Which is not necessarily a bad thing.)
Don’t underestimate the community. I primarily noticed this
attending RailsConf Europe. Almost everybody I talked to really
knew his/her stuff well, and lots were really experienced in Ruby,
too. Of course, it was a rather small and exclusive selection of
Rails users, and they had enough time to learn Ruby until September
2006.
Don’t overestimate the community. Scaling a community is hard, and
Rails soon got into a storm of newbies from Java and PHP camps.
The eager and clever people of these can learn and pick up
everything. The rest proably still lurks in #rubyonrails waiting
for their answers. Just because something was made easy, it
doesn’t mean it’s less complex in itself, there is less to learn or
less to think. Rails may be easy to use, and quick to get started,
but it’s not a silver bullet, and designing, programming and
deploying a real life website is still demanding.
Learn to sell. Before Rails, one rarely saw a screencast, but they
are a great way to convince people of some piece of software
quickly—there is no denying. The whole “PR” of Rails worked very
well in the end. Everyone now knows about it. But also see 3.
Opinions help you and the users. Writing a totally generic
framework without any defaults and conventions turns out to be lots
of effort for the users. The less opinionated the software is, the
bigger the possible userbase becomes, at the cost of passion.
Avoid this. Rather, enable useful (to you) defaults, and make
going beyond them not cost flexibility, but convenience. The users
with vastly different needs will find a different solution (cf. 7).
Gauge evolution and revolution. In the end, Rails is just
meta-programming the boring tasks of web development—there is
nothing really revolutionary, at least compared to more
“advanced” frameworks based on continuations and so on. However,
this technically slight evolution had a huge effect, while a more
revolutionary framework would have had an even harder time to get
acknowledged and appreciated.
Everything has its niche. Many thought that with Rails’ uprising
the other Ruby web frameworks had no chance. It turned out to be
wrong: today there are more Ruby web frameworks that ever (we still
have a long way to go to catch up with Python, though ;-)). If you
absolutely can’t stand Rails, of if it simply doesn’t satisfy your
needs, just check them out. Or write your own.
Mastering anything takes time. It’s rare nowadays, but it
occasionally still happens that I discover a Ruby method/trick/dark
corner that I haven’t heard of before, despite year long learning and
using the language. The same is true for Rails, both for its users
as well as its programmers. Lots of Rails programmers came to Ruby
via Rails, and lots of them probably today bitch as much as me
when I have to read some piece of their early code. That’s not
a problem by itself, but one needs to recognize that even though
doing Ruby for, say, half a year, mastery has not been reached.
Furthermore, if you realize an often used piece of code is written
in a newbie-style, don’t hesitate to refactor.
Success comes after the hype. There have been times I’ve pondered
myself for not really liking Rails, but just like in real life,
people quickly recognized that Rails is not paradise either. Just
about everybody stumbled over some rough parts, got bitten by a
nasty bug, or completely became befuzzled trying to add more magic
to ActiveRecord. And a fair lot admit that Rails could be better
than it is. However, people still use it. Even a big part of
these critics uses it, and some make their money with it. Rails
clearly survived the hype, and still looks good. This can be known
only afterwards, tough.
Make programming fun. With Rails as with Ruby, one often sees the
word “fun” in the same sentence as the word “programming”. As a
hobbyist programmer, I pity people that need to program non-fun
stuff, and I knew all the time that I vastly prefer fun
programming. Guess how happy I was when I found Ruby.