私には何名かの師匠がいる。私は技術力は３流なので、ちゃんとしたプログラマになりたい。だから、イケてる人をみると教えを得るようにしている。見返すことができるように、その内容をまとめておく。
1. 小さなハローワールドを繰り返し、ブログに記録する
私のNo.1 師匠である、かずきさんから教えてもらったこと。彼と Hackfest に参加した時に、APIリファレンスを見ることなく、APIの中身のアーキテクチャまで理解していながら、高速に開発する姿は最高だった。一方私は、何しても人の三倍かかって、しょっちゅう Google のお世話になっている。
彼に教えてもらったことが、このことで、「小さなハローワールド」を繰り返すということだ。何か新しいこと、に出会ったら、難しいことをしなくていいので、自分の手の届くような小さなハローワールドレベルのプログラムを書く。その時に重要なのは、ドキュメントにあるコードをそのままではなく、自分なりに少し変えて作る。そしてそれをブログに書く。
コードを変えるのは、やっぱり自分でできるようになっているかすることもあるだろうし、ブログに書く時に、他人に説明する程で書くのがいい。自分で理解できていないことがその時にわかる。他の人のためにブログを書いているわけではないので、アクセスとかは気にしなくていいが、「他の人が理解」できるように書くことで、理解を深めて、自分にも記憶に残りやすくなる。また忘れた時も便利。
これを実践している時に感じたポイントは、「問題を小さく分ける」ということ。結構難しいが、複数のことが絡み合うから、ややこしい。だから、同時に試す要素は１要素にする。そのために、面倒でも、新しいプロジェクトを作ると良い。人間は難しいことを一気に解決できない。こうしたハローワールドを繰り返しているといつしか高いところにいることに気づくとのこと。このメソッドは相当強力であると感じている。
私のQiita のエントリがそれなのだが、いかに他の人にとってどうでもいい内容をブログにしているかわかるだろう。ポイントは、自分にとってわからないことか、そして、自分にとって小さなハローワールドかだ。だから、他の人にとって役に立つか、とか既知の情報であるかは気にしていない。
ちなみに、他の人に役立ちそうだなと思った時で、英語にも既存のリソースがなさげな時は英語で書いている。
2. コマンドを使ったらその前後で何が変わるかを理解する
どんな技術でも使いこなし、とてつもなく学習が早く、衝撃的な Hack力を持つ Ken さんに教えてもらったこと。彼は、新しいコマンドを使うときは、なんとなく動いたとかではなくて、コマンドを使ったら前後で何が変化するか？を理解するという。diff みたいなものを使って、前後でどう状態が変化したかまでを理解すると良いとのこと。
3. ドキュメントを読む
Ken さん曰く、ドキュメントは、正しい、もしくは、過去正しかったことが書かれていることが基本なので、ここをしっかり読むことが重要という話だった。とても当たり前のように感じるが、最近英語のドキュメントを読むことが多いが、英語だと特に億劫になって、「多分こんな感じだろー」みたいな感じで飛ばし読みすることが多い。そうすると、読み飛ばしていたところに、注意事項が書いてあったりして無駄にどはまりしてしまったりも良くする。私の場合英語力がいまいちなのでそれでもミスることも多いが、まず焦らずドキュメントを読むところから始めている。
4. ジタバタしない
同じく Ken さんのアドバイスで、何かに詰まったら、そこであーでもない、こーでもない、と試行錯誤しないということ。まずは、誰かに聞く（MLなど）そして、投げた後は他のことをする。確かにそっちの方が効率が良い。やはりジタバタの時間はいつも相当無駄になっている。
5. トリプルディスプレイを使う
Ken さんに、ディスプレイ４つだと扱えない。３つが最高と聞いたので、実際やってみた。これは最高だ。持ち運び用のセカンドディスプレイも検討中。後、エディタのショートカットとか、terminal とかのコマンドは、時間をかけて覚えた方がいいとのこと。普段動作のものなので、生産性に効いてくるからとのこと。
6. ARM を愛でる、コードを読む
これはインフラ野郎、真壁さんの教え。彼に、なんでどこにもドキュメントに出ていないような情報を知れるのですか？と聞くと、疑問に思ったことは、MLで聞いてみたり、試しているみたい。Managed で背景は一瞬見えなさそうでも、どう動いているかを把握されようとしていた。また、AKS の仕組みの調査も、ARMを愛でたりしているらしい。それでビールが飲めるらしい。他にアーキテクチャ的な部分も、コードを読んで確かめている様子。彼から聞いたのではないが、疑問があったらほっておかずに、調べてみるのがいいのかもしれない。確かにどうしてもわからなければ、聞けば良いかも。
7. ビデオを見る、アーキテクチャに時間を使う
同僚の超絶センスいい Kanio の言葉。コードを書いてばかりではなく、アーキテクチャにも時間を使うのが重要らしい。なぜ、そんなインターナルを知っているのか聞くと、ビデオをみたり、わからないところを質問したりしているとこのこと。コードと、アーキテクチャのバランスを取るのが必要らしい。そういえば私はコードばかりで、こちらの方はやっていなかったので、もう少しこちらもやってみる。
8. わからないところは質問する
達人から複数いただいた回答で、インターナルの様子など、わからない時は、質問する。確かに単純だけど、ドキュメントなかったら諦めてしまっていた。やってみる。
9. マイクロソフト内で検索する
マイクロソフト内限定だけど、社内の検索サイトで検索すると色々情報が落ちているらしい。それを読んでみる。
10. ログやメッセージを読む
イケメンを観察していると、自分だとあまり気にしない、画面にでているログとか、メッセージをちゃんと読んでいる（自分よりずっと早いけど）。自分は遅いのでゆっくりだけど、コマンド叩いて出てきたものに注意を払おう。
まとめ
このブログも自分のためにまとめてみた。今後こっそりアップデートされるかも。