情熱プログラマを読んだ概要とか感想とか ~ その2
二章 製品に投資する
才能だけでなんとかできる人もいる。筆者のサックスがそうだったが、才能で演奏して練習をしなかった。
その後エンジニアに転向しサックスは趣味程度になったが、そのようになったからこそ大事な場面では練習をするようになった。
そうなる自然と、才能だけで吹いていた時よりもテクニックが上手くなったと感じる時が出てきた。
だからこそ、製品(自分)に投資する重要性をここで解説していく・
魚の釣り方を学ぶ
魚を与えれば一日の糧になる。だが魚の釣り方を教えれば一生の糧になる。
ソフトウェアでもそうだ、使い方を教わればその日の知恵になるが、どう動いているのか知っていれば顧客への説明もしやすい。
そのために自分で使っているツールの勉強をするべきだ、この時教わるといってもそんな人はすぐに現れない、だからこそ自分から学んでいくんだ。
この考えは重要だ、普段使っているツールが移り変わっていくなんて、フロントエンドじゃよくあることだ。
だが中身を知っていればこそ代替物が出た時に、その知識が役立ってくるものだ
この辺は一生の"先んずるか、やられるか"の知識かな
ビジネスの仕組みを学ぶ
我々はITのスペシャリストだ、だからこそそのプロジェクトでビジネスに協力する。その為には完璧でなくてもいいが、少しでもこれによって利益を出す仕組みを理解していなければいけない。
請負とかの契約周りならある程度理解しているつもり、転職する時散々言われ、絶対に騙されないと言う意思を持っていたから。
ただ、一つの会社のシステムを見る側になるのであれば、それだけではいけないのだろうな。方向転換する場合は改めて考え直すべき事
師匠を探す
師匠がいれば先へ進む道筋もわかる。限界と思える地点も長くなる。成長も早くなる。
今の時代ならば技術顧問なんかはとてもいい師匠と言えるだろう。そう言う方がいる会社は羨ましい。
私はないから探すしかない。まず大海に出るところから始める。
師匠になる
師匠は解雇されにくい。経済的に不安定になったとしても、人を助けられる仕事は価値が下がりにくい。
人に教えることは自分の知識を深めるためにとても良いことである。
コミュニティで人に教えると言うのはとても良いのだろう。
私自身は一匹狼的考えなので、本当にそれほどメリットがあるのか？なんて考えてしまう。
教えたところでどこかいってしまう人ならば、意味がないように感じてしまう。(別段人に教える経験がないわけでもないし、むしろ好きではあるが…）
この利点は帰ってくるのに時間がかかるものだと思うので、少しづつやっていくしかない。
帰ってきたら楽しく思えるだろう。
一に練習二に練習
限界ギリギリで鍛えろ。仕事なら完璧を求められるが、練習なら完璧じゃなくていい。
練習にも種類がある。音楽にたとえてカテゴライズするならば、1.身体的技術 2.初見 3. 即興 となってくる。そう考えるならばIT分野での練習もたくさん種類があるだろう。
こうやって本を読んで、アウトプットすることも一つの練習として考えている。これはアウトプットの練習、本を読む練習、概要をつかむ練習としてやっている。
プログラム的な練習ならば、反復や初見や理論の組み立てなんかをやりたいところだ、
反復なんかは新しいものをどんどん作っていけばいい。初見も本見ながら進めよう。理論の組み立ては、ATCoder再始動するのもアリだな。
それら全てに繋がるのがアウトプットだと思い、今やっている。
プロセスを大切にする
開発プロセスを一番ものにするには実際にその導入に協力することだ。問題点や利点を議論しあい賛同を得る。計画をまとめて実行する。
* おそらく私だけじゃなくほぼ全ての人が考えていることだろう。
プロジェクトを成功させたい。そんなのみんなそう思っている。じゃあどうやって成功に導くんだ？って話だ。
私だってそう思って進めている。こうやったほうがいいんじゃないか？なんて考え一歩進むごとに出てくる。
その中で議論し賛同を得るための方法を考えていくべきだ。
実際に自分でやって利点欠点洗い出してその上で議論し会う必要があるだろう。それをやっていこう。
巨人の肩の上で
既存のコードを掘り起こせ、巨匠のコードをくまなく研究しろ。その上で自分の実力を思いしれ。
今はGitHubとかあるからいろんな人のコードを見れるいい時代だと思う。
私も多くの人のコードを見るし、RailsやってりゃRailsのコードもちょこちょこ見ている。
そう言う人のコードは正直何をやってるんだか理解に時間がかかるし、それが自分の実力なんだと思う。
簡単なgemでも実際に動かして理解するだけでも勉強になるから、そこから始めていこう。
自動化によって仕事を確保する
仕事て直面する問題点として、低コストの開発者を大量に雇うか、高コストの開発者を数名雇うかと言う議論がある。
もちろんこちら側としては後者の方がいい事はわかっているが、それを経営者に納得させるための根拠が存在しない。そのため経営者は同じようなものとして考えてしまう。
生産性を上げる方法は何点かある。1. 作業員の開発スピードを上げる。2. 作業員を増やす。3. 作業自動化する。
1は根拠がない、2はよくない、であるならば3だ。
自分の書くコードを自動化しよう。
Rubyやってればわかる。私は飯を食うためのコードを書くコードを書くんだ。そのためには魔術師にだってなるさ。
この考え方は私は好きだしあってると思っている(もちろん力に溺れないように気をつける)。であるのならばどんどん進めていこう。
コードジェネレータを作り、MDA(モデル駆動開発)を調べ理解していく。
