I've been doing a fair amount of Ruby on Rails programming recently, related to which is a program named "Zen". In my Google search for more information on this app, which comes highly recommended, I'm seeing a lot of hits for people saying that coding with RoR is a very Zen thing and that things are happening by not happening and so on.
I'm a big believer in determining and working at the right level of abstraction for what is being built. If you're writing an OS kernel, you should not be working in Scheme. If you're creating a website, perhaps C is a tad bare metal for the task at hand. What is so nice about Ruby on Rails is that it has found the right balance at the appropriate level of abstraction, and that's exactly why people are so productive with it. It implicitly enables a lot of functionality for you without you having to tinker, but if you want to override the behaviors you have the mechanisms to do so. That's due to a combination of the Ruby language itself and the Rails framework.
Does this mean things are happening because they're not happening? No of course not, working at a higher level of abstraction is no excuse for not understanding what's going on under the hood. To operate with the best in the business you should understand how things work start to finish, and down to the bare metal. You will hopefully not need to get into that detail most of the time (unless you're coding the OS kernel, of course), but when things start blowing up the best programmers know how to determine what's going on (no matter how black box the situation is), and then based on that and their complete knowledge of the system they can make the right decision about changes, workarounds, etc.
A hiring issue we often had at Microsoft is that many people who have been educated on hiring level languages are abstracted away from too much of how computers actually work, to the point where they don't even grok pointers. This is a huge problem, if everything works 100% as you expect you'll be fine in a high level language but the second things fall apart you need to fundamentally understand what's going on under the hood, otherwise people resort to the computer equivalent of hitting the side of the TV with a hammer until the symptom goes away.
I think the best way to learn how to program is to start with circuits and logic gates, work your way up to assembly, then C, C++, Java, C#, and on up until you reach Scheme/Ruby/Smalltalk. Understanding what's going on at the different levels and why means that when you get abstracted away from that with a higher level language you understand both what you're gaining and what you're losing in the process. You can make educated decisions on when you need to drop down an abstraction level in order to solve a problem better, and when you can pop up for better productivity.
A key skill when using a framework such as Rails is understanding what is happening under the hood. Treating it like a black box makes things worse, not better. The productivity gains aren't magical, they're from someone else having already written the code you would have to write if you weren't working with the framework. RoR gains much of its productivity from making it so straightforward to leverage that code, but the downside is that when things go wrong it can be very cryptic why. How do you debug why code you don't know exists isn't being called in a way you don't specify?
