二行で：
公式ドキュメントとソースコード読め。
自分の身の回りのドキュメントとソースコードも読め。
はじめに
「エンジニアが読むべき○○」とか「新人プログラマに読んでほしい記事」などという記事が多々あるが、おおよその場合、一部の条件に特化しているか（特定の言語、フレームワークなど)、本当に大事なことを書かれていないか、くだらないか、なので、本当に読むべき情報リソースを書いておく。
足りないところを補完する目的なので、私の一記事ですべてを網羅しているわけではない。
この記事は自戒の意味が大きいが、たぶん万人に当てはまるのでQiitaで公開しておく。
公式ドキュメント
エンジニアが読むべき○○シリーズでは、書いてはいけない決まりでもあるのか？ってレベルで決して書かれない。
まずは公式サイトを読むのが基本中の基本。
QiitaとかStack Over Flowとか個人ブログとかその他は、まず公式サイト当たってからそのサポートとして読むべき。
ほとんどの場合公式は英語だが読め。
公式チュートリアルや、公式本など、公式○○シリーズは基本的に読む（やる）。
ものによっては、国際機関で公式な定義がされている場合があるのでその場合はそれを読む。
自分が使う言語やプロジェクトのソースコード(OSSの場合)
初心者にはハードルが高い面もあるが、ちょっとずつ読み進める。ソースコード読んどくだけで解決する課題は多い。
自分の使うすべてプロジェクトを読み解くことは時間的に不可能だから、何を読むべきか勘が必要になる。
自分が使う言語で書かれた大規模プロジェクトのソースコードなどもここに入る。
古くからある大規模プロジェクトは負の遺産が多いこともあるので、新しいものも混ぜる。
自分がかかわっているプロジェクトのドキュメント、ソースコード.etc
有象無象な記事を読むより自分のかかわるプロジェクトの情報をちゃんと読もう。
質が高くない場合もあるが、自分のためにはなる。
まとめ
公式ドキュメント、ソースコードと自分の身の回りにあるものをないがしろにして、Qiitaとかニュースサイトとか、動画とか紹介したところで対した意味はない。
そういったものは興味をもつきっかけにはなるが、公式を読まねば正しく重要な情報を身に着けることはできない。
甘い言葉に騙されずまずは公式を読め。
もちろん面白い記事がためにならないわけではない。
ただ、公式をすっ飛ばして学んだ気になるならそれはまやかしである。