めもりー @m3m0r7 CTO at Liiga, Inc. / ex- CTO at a EdTech company / PHP で RubyVM, JVM, OS など自作 / 「レガシーコードとどう付き合うか」「Swoole で学ぶ PHP 非同期処理」など拙著いくつか / 🐈の生まれ変わり i.mem.ooo

noteからの転載 技術書を初めて読み始めた頃、ビジネス書とかマネジメント論みたいな本と違って、書いてある通りにやれば動く、凄い！って思ったけど、すぐに「書いてある範囲のことしか動かない…何も分からない…」という所に行くんだよね…— magnoliak🍧 (@magnolia_k_) December 6, 2020 一人で技術書を読むときに陥りがちなんだけど、そのソフトウェアの持つ独特の箱庭感みたいなのが有ると思っていて、技術書に書かれていることは（前提のバージョンとかが変わっていない限り）、まぁ動いてしまう。 そして、動いて、「やったー」と思った先に、「で、次に何をやるの？やりたいことってあるの？こんな面倒くさいをことを続けるの？」というフェーズがやってきて、なかなか先に進まない、ということが有って。 特に職業プログラマーであれば、職務上やるしかないけど、将来のための勉強などでやって

技術書、一度読むだけでなく、しばらく経ってから読むことで新しい発見があるので、分からなくてもいいからまずはざっと読むと良い、という話をしました— magnoliak🍧 (@magnolia_k_) November 6, 2020 特に設計思想的な話は、自分の経験によってどんどん見え方が変わるから同じ本でも何度も読み直した方がいい。 本を理解するのではなく、本をきっかけに自分の考えを整理するのが目的だからね。 と、以前noteに投稿した。 そして、そのあとに、「一冊の本をじっくり読み込み、知識を吸収するためにはどうすればいいのか」というエントリを書いた。 blog.magnolia.tech 非常にコメント付きのブクマが多く集まり、色々な知見が得られた(ちなみに、私も全部あんなディープな読み方をしているわけではないです、念のため）。 その中で、古い本だけど今でも読み継がれている本の読み方