技術書読むの苦手なんですよね

study.md

何が言いたいのか

• 「技術書を読まなくていい」と言っているわけではない
• 「プログラマー・エンジニアだから技術書をたくさん読んで理解しなければならない」という価値観にとらわれる必要は無い
• 人によって物事の得意な認知の仕方は異なる
• 自分に合った学習スタイルを見つけられるといい
• もしくは、本の読み方にはコツがある

技術書読むと眠くなっちゃうんですよ

• でも周りはたくさん本読んでる人いて大変
• 「読んだ方がいい」と言われる本がたくさんあって大変
• 「俺はダメなやつだ...」となり自己肯定感下がって大変

「プログラマー・エンジニアだから技術書をたくさん読んで理解しなければならない」という価値観にとらわれることをやめた

• 「技術書を読まなくていい」と言っているわけではない

人によって物事の得意な認知の仕方は異なる

• 認知特性 というものもある
• 認知特性のテストでも、文章による認知能力は低めという結果が出たりしたので、まあそんなもんかな〜ぐらいの受け止め方をしている

自分に合った学習スタイルを見つけられるといい

• 手を動かすものを中心にやっていく方が自分にあってると自覚してる
• 例えば新しい言語やフレームワークを学ぶ際は、チュートリアルを探して先にやる
• 同じお題を異なる言語・フレームワークで実装したり解いてみたりするのも好き
• その後で問題にぶつかったり、深掘りして学びたくなった時に本を読む
• もちろん最初に本を読みたいのであれば読めば良い

もしくは、本の読み方にはコツがある

• 問題にぶつかってから読むのが一番効果的（個人の感想です）
• 最初に読む時に「内容を理解するために読み込む」ことは少ない
• 目次をザーッと眺めて、本文をサラッと読んで、単語などからなんとなくの記憶のINDEXを用意し、必要になったタイミングで引っ張り出して読み返す
• 繰り返し読んで、理解を深める
  • 1回読んで全てを理解する必要はない
  • 時間が空いてもいい

補足: 「問題にぶつかってから読むのが一番効果的」について

• しかし問題にぶつかった時「この本に書いてある」というINDEXが無いと読めないという問題がある
• 上司や同僚のフィードバックや、外部の情報などから適切にサジェストされるのが理想的ではある
• また、「問題にぶつかっている」と認識するためには「この状況が問題である」とわかる必要があって、「この状況が問題である」とわかるためには知識が先に必要であるという、鶏卵問題がある
• そういう時のために、読み込むんじゃなくて記憶のINDEXを作る程度にサラッと読んで、必要になったら取り出すのは有効

何が言いたいのか

• 「技術書を読まなくていい」と言っているわけではない
• 技術書読むと眠くなっちゃうんですよ
• 「プログラマー・エンジニアだから技術書をたくさん読んで理解しなければならない」という価値観にとらわれる必要は無い
  • 「技術書を読まなくていい」と言っているわけではない
• 人によって物事の得意な認知の仕方は異なる
  • 認知特性 というものもある
• 自分に合った学習スタイルを見つけられるといい
  • 手を動かすものを中心にやっていく方が自分にあってると自覚してる
  • 例えば新しい言語やフレームワークを学ぶ際は、チュートリアルを探して先にやる
  • 同じお題を異なる言語・フレームワークで実装したり解いてみたりするのも好き
  • その後で問題にぶつかったり、深掘りして学びたくなった時に本を読む
  • もちろん最初に本を読みたいのであれば読めば良い
• もしくは、本の読み方にはコツがある
  • 問題にぶつかってから読むのが一番効果的（個人の感想です）
  • 最初に読む時に「内容を理解するために読み込む」ことは少ない
  • パーっと読んで記憶のポインタをなんとなく用意し、必要になったタイミングで読み返す
  • 繰り返し読んで、理解を深める

誰？

• 「技術書を読まなくていい」と言っているわけではない
• onigra
• Classiという会社で開発組織の部長をやっている