(Consider this an entry for the contest.)
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, though.
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.
NP: Bob Dylan—Visions Of Johanna