ここに書いてあることは全て、何年か経験したエンジニア/プログラマなら 体感で理解している ことばかりですので、この投稿はあまり役に立ちません 
偉そうに書いてるところは、自戒を込めて書いてるので気になさらず.. また、ある閾値を超えた上位のエンジニア/プログラマには、別の経験則があるでしょうから、私には良く分かりません^^;
タイトルが長くなるので「開発言語/フレームワーク」としましたが、ライブラリやツール類の習得も同じ話だと思います。
① 書籍を読むのは初めは最大2冊まで
もし書籍が発行されていれば、それを読むのがてっとり早いのですが、読むのは 2冊まで に抑えた方がよいです。
できれば 1冊 ですが、複数冊を読むのは、一方の足りない部分/分かりづらい部分を 補完しあう 異なる視点から理解する というメリットもありますから、良書があるなら 2冊 で。
それ以上になると 許容量オーバー です。身につかず、全てのこと網羅したくなる気分になるので。（かくいう私も、いろいろ読みたくなる性質ですが..）
また書籍を読む際は、例えば構文や関数を 暗記する のではなくて、 言語の理念や特徴 を読み取るということを意識します。
（昨今はエディタ(IDE)が自動で補完してくれますし、困ったときに都度、チートシートやリファレンスを見ればよい。）
また、他に気をつけることは、
- 深い意味は 追求しすぎない 、完璧さを求めない
- 単にそういう仕様ということで、 そもそも意味がないことがある
- どうしても理解できないことは 飛ばしてもよい
- 後述の「コードを書く」のあとで、戦闘力があがったら 読み返す つもりで
- そもそもの説明が悪いことがある、書籍も完璧ではない
- おなじく レアケースっぽいもの は、許容量を超えそうなら飛ばす
繰り返しますが、暗記でなく 理念や特徴 を読み取る、です。
例でいうと、JavaScript であれば参照の挙動とオブジェクの性質が分かると、あとはその応用でしかないことが分かります。
「何が良書か」は識者に聞くか、分からなければ安定のオライリー本で良いかと。
ちなみに Amazon で売れてる本が良い本とは限りません。敷居が低いものが量として売れる、ということもあるので。
[2014/12/10追記] 逆引き系の書籍で何ができるか眺めるのも効果的かと。
② とにかくコードを書く、手を動かす
Don’t think, feel（考えるな、感じろ） 〜ブルース・リー〜
絶対にNGなのが ひたら座学(書籍)だけで学ぶ または 書籍を読んで分かった気になる です。
とはいえ、何も分からないうちは何も作れないと思うので、その場合は、
- チュートリアル的なものが用意されていれば、その通り書いてみる
- 面倒でもコピペしてはいけない、実際にタイピングする
- 書籍に書いてあるコードを写経する（そのまま書いて動かしてみる）
慣れてきたら、自分でちょっとしたものを何か作ってみます。が、絶対に詰まるので、その時点で 書籍へ戻り ます。すると、また書籍の内容が 違った視点で頭に入ってくる のが実感できるかと思います。
ここは実はこういうことだったか、というのが見えてくるのと、ポイントというか重要度の強弱が分かるようになる。
ですので、書籍は 後から見直すもの なので、はじめから全てを理解している必要はありません。
あとは、書いたコードの量だけ知識は増えるかと思いますが、もし業務で迫られておらず機会が無い場合は、
- いま 自分が困っていること を解決するものを作る
- 自分が面白いと思うサービスやアイデアがあれば、それを実現していみる
- 業務にアサインしてもらう（必要に迫られる状況を作る）
- セミナーや勉強会での発表を、習得の前に先に決めてしまう
などとすると、モチベーションが継続するかと思います。
③ 学習曲線を知っておく
正しい学習曲線の定義と合っているか分かりませんが、まあイメージで。時間(横軸)と理解度(縦軸)の関係は、下図のような感じかと思います。（時間の長さは、学習対象による。）
初めは停滞 しているのですが、手を動かしていると ある時点で急に理解分かる ようになり、次のステップに行くには また停滞 し、の繰り返しです。
ダイエットと一緒です！
なので、停滞してもそういうもんだ、と理解しておかないと、早々に諦めかねないで、これは知っておくと良いかと思います。
④ 時間でなく期間が必要
これはあまり周りにそれほど理解を得られないのですが、私の経験則です。学習の総時間でなくて、ある程度の「期間」が必要だと思います。例えば 1日に10時間 の学習をするよりも、5日で2時間づつ の学習をした方が効果的、ということです。
理由：
- 人間の脳は、一日に吸収できる量に限りがある
- 脳に記憶させるには、反復が必要
- 人間は寝ることで脳に情報が書き込まれる
別の言い方をすると、時間をかけて 脳(手)に馴染ませる という感覚でしょうか。さらに別の言い方をすると 既視感 です。
何かコードを見た時に この構文や設計は見慣れているなあ という状態を作ることです。すると、その部分は馴染んでいるわけですから、それを積み重ねていけばいいです。見慣れたものが基盤になって、次のステップに進める、という感じです。
また期間について補足。日頃、ネットの技術情報を拾っていれば何となく知識が得られますし、お風呂に入っている時や会社の行き帰りの電車で何となく考えたりするわけで、そういった意味でも期間は必要かなと思います。
学生時代に一夜漬けを経験している方は、なんとなく分かるかと思います。
⑤ 大元を参照する
言語/フレームワーク/ライブラリ/ツール本体のソースコードが公開されているものは、それを読みましょう。最近は GitHub 等で公開されているケースが多いかと思います。（その時点で読む力があれば。）
所詮プログラムは、自然現象や生物と違って あらかじめプログラムされていること以上の動作はしない です。
また、公式のドキュメントがあれば、それを読みましょう。ただ IT技術界隈 だと英語のものが多いので、英語力が求められるケースが多いですが..
英語が苦手なら、日本語訳のものを。ただ、翻訳の更新が追いついているかは注意です。
私は昔、Apache の挙動で分からないところがあったのですが、最終的には Apache 本体のソース(C言語)を読むところに行き着きました。結果、最初から読んでおけばよかったなあと後悔..
また、「学習コストが高い」と言われる AngularJS ですが、挙動が分からずググるより、本体ソース見たほうが早い(らしい)です。
https://github.com/angular/angular.js
⑥ 識者に聞く
周りに識者が居るなら、ポイントを聞いちゃった方が早いです。もちろん言語でいえば構文等を聞くのではなくて（親切な方だったら聞いちゃってもいいんだけど）、 言語設計の理念や特徴 、 背景/周辺環境 、そして 何からどうやって学べぶべきか です。
⑦ 仲間を作る
ひとりで学習するより、仲間が居たほうが刺激になりますし、教えあったりもできます。具体的には、
- 近くの人をそそのかして？、一緒に学習してもらう、布教する
- 社外、社内(あれば)の 勉強会 に参加する（できれば懇親会も）
- 技術コミュ二ティ に参加する
- 次節に書きますが ブログとか 書いていれば仲間が見つかるかも？
⑧ 文章でアウトプットする
なぜ世の中のエンジニアがブログを書いたり、Qiita に書いたりするのか。それは何かのアピールでしょうか？そのような目的が数パーセントあるにせよ、実際は次の効果があるからです。
- 文章で「まとめる」ことによって 体系的な理解 が得られる
- まとめる過程で、理解や検証が 足りないことに気づく
- ⇒ その場で調べたり、検証したり
- ⇒ その後の学習の課題へ
- あとで「自分」が見るためのメモ
- 時間が経つと 忘れる
- いったん頭から追い出せるので 新たに知識が入る余地 が脳に生まれる
極論、人に公開しなくても手元のメモでもいいと言えばいいのですが、そうなると恐らく 自分だけが見るので手を抜く のが人間かと^^; また同じ興味がある人とつながれる、外出先でネット環境があれば自分で参照できる、という利点もあるかと思います。
個人的には、自分だけのクローズドな知識は何も価値が無い、と思っています。また、まとめられない知識というのは、単なるバッドノウハウの蓄積にすぎないかと。
また、アウトプットを継続していくと、次のような効果があります。
- 他社から 反応がある ことが刺激になる、モチベーションとなる
- 反応を得るために学習するというサイクルが出来る
例えば Qiita のストックとかはそうですよね。
あとは道徳っぽいですが 人に教えたことは廻り回って自分に返ってくる というのが感覚的にあります。
ライブラリやツールを作って、GitHub 等に公開、というのもいい手です。
なかなか文章にまとめる気力が起きないなら、上にも書きましたが「セミナーや勉強会での発表を先に決めてしまう」で、その資料づくりを通してまとめます。
⑨ 必ずいつかは理解できる
止まない雨はない 〜出典不明〜
身につかない間は苦しいかもしれません。ただIT技術全般に言えることなのですが、習得期間に長い/短いがあれ、たかだか 人間が作ったものなので人間が理解できる 程度のものです。（そうでないものは、そもそも世に流通していない、利用しているユーザが存在しない。）
上記にも書きましたが、コツコツ手になじませ、脳に既視感を持たせ、言語理念を想像＆手元で検証していけば、必ずいつかは理解できます。
⑩ あれこれ手をだしすぎない
これは自分がそうなる傾向があり自戒なのですが^^; 最初からすべて網羅しよう、すべて理解しようと思うあまりに、また詰まった際の現実逃避で、色々な書籍に手をだしたり、補助的なライブラリやツールに手を出したり（そしてその使い方について悩む..）、いまやっている方法とは別の方法を模索したりした結果 時間だけが過ぎていき何も身につかない ということになりがちです。
繰り返しになりますが、焦らずに一歩一歩、着実に進めていくのが最短ルートなのかなと思います。
〜おわり〜
PS. どうでもいい話ですが、ブルース・リーの名言は、何か本件に通じるものがありますね 
⇒ 武道家【ブルース・リー】の哲学的名言