That's one of my favorite books. You could also say that this is an application of Be Proactive (decide what technologies you want to learn rather than only using the technologies handed to you) and Begin With The End In Mind (I eventually want to be an expert AngularJS developer with plenty of production experience).

Sharpening the saw is actually not the same. It means taking a break from what you're doing to come back more effectively at the task in hand.

You can come pretty close. For example, I spend maybe 15-20 hours teaching myself AngularJS, and then the next AngularJS work I did was paid work.

Also, if you get a job where you have at least partial control over the technologies you use, you can of course get paid to use a technology with which you have no experience.

I would actually prefer to get a little non-paid experience first, though, in fairness to the person paying me. (Unless the boss/client is cool with paying me to learn.)

I got a job as a Rails developer without knowing Rails. Here's how I did it.

I went out to local community events with a focus on software and networked with other developers. Word got out that I (a student at the time) was a competent developer with open source experience. When I graduated, a few of my new developer friends tried to recruit me.

I took a job at a local startup as a software developer. I was going to build a new product, though the tech stack wasn't decided yet. Soon it was decided to be Ruby on Rails. I worked through the Rails guide on building your own blog, then continued to learn it on the job by doing a small project that shipped. At that point I had enough experience to design the important project and start building it.

It's worth noting that while learning Ruby/Rails, I completely surrounded myself with resources. I would answer questions on StackOverflow, follow Rails blogs, watch screencasts, hang out in the IRC channels, read and review Ruby books, watch and learn from public projects on GitHub, etc.

This is good advice but it really depends on whether the client/company views software as a revenue driver in its own right, or a means to an end.

For places that use (not make) software, the best bet is always to focus on solving the client's problem in as economical a way as possible, irrespective of the technology used.