ポエムというか、雑記。
このブログでそういうの書くの実は初めてかも。
これから気分転換にこういうの書きたいです。
（いまも寝れなくて深夜4:00から書き始めてる）
長期休暇の季節になるとIT技術者向けに本を勧めるエントリが出回る
Google検索 エンジニア おすすめ 本
Google検索 新人 エンジニア おすすめ 本
長期休暇前だけじゃなくて、まぁ定期的にこういうエントリは出ます。
rebuild.fmというIT技術者向けのPodcastがあって、
僕はそれをよく聴かせていただいているんですが、その中で、こういったエントリに対する
言及があり、それをきっかけに僕も考えたことがあったので、書いてみました。
僕の立場
社会人もうすぐ4年目になるところで、業界全体で言えば、新人でも
プログラミング初心者でもない状態なはず。
プログラミングのスキルや経験的には、全くそんなことないんですが、
コンテキストによっては上級者とも取られるケースもあります
（例えば、IT技術に関して全く知識のないクライアントさんとのやり取り上とか。）
ようするに脱新人・初心者を比較的最近していて、かつ、これから新人をたくさん迎えて、
場合によっては、教育（というとおこがましいけど、業務上サポートをしたり責任を負ったり）
することもある立場。
僕がプログラミング初心者だったとき
技術書を読むこと、そのものが比較的好きだったので、当時から
こういったエントリは自分から探して、上から順番に購入して読んだりしてました。
中には、初心者にとってはあまりにも高度な前提知識が要求されるような本もあって、
買ったけど『全然理解できない』みたいな事はありました。
それでも『あー、上級者っていうのは、こういう内容も理解できないとなれないんだなぁ』
とハードルの高さを感じつつも、ポジティブに『読めるようになったらまた挑戦してみよう』
くらいの気持ちでした。
なので 個人的にはこういうエントリは大変ありがたかったし、非常に為になった と言えます。
でも。。。
『新人に勧めたい本』みたいなエントリを閲覧してる時点で、そこに関心があるとして、
その本を読む（つまり結果的にもっとプログラミングやソフトウェア開発ができるようになりたい）
というモチベーションを無駄にしたくないな、と思います。
しかし、そういった記事のおすすめされた本を、片っ端から買って読んで見る、っていうのは
プログラミング初心者にとって、問題もあると思っていて、それが以下。
- 技術書はそもそも、本としては安い買い物ではない
- (内容的には安いんだ、みたいな主張は一旦置いといて)
- 普通の学生が買うには特に。
- 買った本が無駄になるとモチベーションの低下を招く場合がある
- 大体の人は、よりプログラミングをできるようになりたくて、本を買う
- 内容が理解できない、小難しくて単純に読んでてつまらない等
- 僕の思想としては、基本的に『ハードルが上がる』というのは悪
- ここに対しては、色々なご意見があると思いますが。。。
- 比較的簡単に、楽しく、より多くの人がプログラミングを学んで、自分で書けるようになったらいいな
- それが、リテラシが上がる、（プログラマにとって）つまらない仕事が減ると信じてる
- おすすめされているコンテキストを、初心者が理解することが難しい場合がある
- エンジニア全般なのか、Webなのか、ゲームなのか、アプリなのか、インフラなのか
- この辺が書いてあることも、よくあるけど、書いてあることを理解できない層も読んでいる
僕が初心者じゃないプログラマになって
業務上、たしかに『こういう前提知識あると、コミュニケーションがスムーズにいくなー』
みたいな事は当然あって、そういうのは大体体系的に書籍化されていたりするので
『新人にオススメしたい本 XX選』みたいな記事を書きたくなる気持ちは、とても理解できます。
ただ、僕が書くなら、書きたい自分のためではなく、求める新人のために、そういうエントリを
書きたい。(書かないけど)
どの記事もそういう体になってはいるけど、押し付けっぽさは確かに感じてて、
『こういう本を読めよ』って言いたいだけだろ、みたいなのあるなー、って
今だと思います。(初心者のときは、それすらわからなかった)
あと、新人教育を書籍に押し付けたくない。（教科書にはするけど、読んどけ、は雑。）
オススメしたいんじゃなくて、読んでおいてほしいんだよね、書いてる人が。
ならそう言ってほしい。(それなら仕事して読むよ。)
そんなこと言ってない、と言われたらそれまでだけど、そう感じちゃう時あるからすいません。
本題1. オススメの本を列挙した記事を書きたい方へ
まとめると 対象者を限定的に、かつ明確にして、前後のパスも一緒に見せてくれ ということ
- 対象者を明確に書いてほしい
- どういう業務(仕事じゃなくてもいいけど)を行うエンジニアに向けてなのか
- ネットワークの本と、Railsの本とか、ジャンル違う本すすめるとき
- Railsの人がネットワークの本読んだのか、ネットワークの人がRailsの本読んだのか、でも大分違うと思う
- 読んだ人は、いつ読んだのか、なんで読んだのか、結果何か解決したのか
- いま読まなくても、『XXXに困ったとき』に読んだら役に立つかも、みたいなのわかる
- 難易度や前提知識も書いてほしい
- 理解できなかったら、これ勉強すればいいかも！みたいなパス
- もっと知りたいなら、みたいなのもあると、それ好きになったときに嬉しい
- その本のいいところ、悪いところ
- 特に悪いところが書かれない傾向が強い
- 往々にして、古典を勧めて、内容が古いこと、読みやすい類似本に言及しない
- 本当に読める冊数をすすめて欲しい
- 春休みのシーズンに『入社前に読みたい、おすすめ100冊』とか。読めると思ってやってんのか、と。
- だいたいこういうのは、ごった煮の、出てきた名前全部列挙してるだけの内容
個人的に『XXXな技術者 YYY人にアンケート』みたいな多人数の意見で作成されたエントリは
上記の点が薄まるので特に気になる。
大前提として、一応書いておくと、 勧められてる本は素晴らしいものばかり、エントリが悪い と言いたいです。
本題2. オススメの本を知りたい初心者プログラマの方へ
こういう前提で本を選べたらいいのかなー、と思います。
- 全部読む必要ない
- 勧めてる人も、読んでないと思う
- 古い本が、だいたい含まれています。
- Joel on Software
- Pragmatic Programmer (達人プログラマ-)
- オブジェクト指向における再利用のためのデザインパターン
- 計算機プログラムの構造と解釈 (SICP)
- The Art of Computer Programming シリーズ
- このあたりは、よく挙げられていて、かつ古典と言われる本
- 内容が誤ってるとかじゃないです、ただ内容を絞ってわかりやすく書かれた他の本がたくさんあります。
- もちろんオリジナルは機会があったら読んでみるのもいいです、でもこれが導入じゃなくていい
- 大体小難しくて、読みづらいです。
- ここに挙げてなくても、そういう本はいっぱいあります。
- 余談ですが、それでもリファクタリングとEffective c++とかは今でも読む人多いのすごいなー
- 言いたいことを言うと、この辺をガンガン挙げてる記事が特に嫌い。他を読んでないか、これくらい読めよなっていうのを感じる
- 何を勉強したいかはっきりしてるとGoodかも
- 全体を俯瞰したくて、なんとなく有名どころ読んでみようかなー、ってときもありますよね。
- そういうときは、特定のミドルウェアやプログラミング言語に偏らないやつがいいかも
- でもやりたいことドリブンは強い
- 楽しく読めるやつを適当に読むのが一番
- 読んだ = 身につく じゃないので、読むのに体力使いすぎるともったいないかも
- 読んでみて、しっくりきたらもう一回読んだり、実践に使ってみたりーくらいなノリで。
エッセイや開発手法の書籍って、実際につらさ体感して、それから読んで
『あーーーーわかるーーーー、つらいよねーーーー、これで解決できるかもなーーー』みたいな
気付きあるので、いつ読んでもいいけど、個人的には実際に業務やってみて、つらかったら気分転換に
読む、とかがいいかなーって感じました。
ディスるならお前が書けよと言われたら
聞かれたら、個人的な意見を直接本人に伝えるスタンス
偉そうに書けるほど読んでないし、読まなくても、業務上進むなら問題なくて
あとは、本人が読みたいかどうか。好きなら本を聴くし、好きじゃないなら方法聴いてくるでしょう。
と思ってます。
s