技術イケメンになれるブログの書き方
最近、インフラいじり、プログラミングの両方に有効な自分なりの Tips を発見したので、シェアしておきたい。
ブログは技術イケメンになる最強の武器
私にはプログラミングのメンターが３人いる。特にかずきさんには大変お世話になっている。彼と一緒に仕事をしたときにあまりの強烈な技術力に衝撃を受けた。どうやったら彼みたいになれるのか聞いたところ
何かを学んだらブログを書く。そのまま書くのではなく、自分なりにプログラムを書くようにする。それだけ。
というお話をいただいて、それ以来私はずっと学んだら誰にも読まれなくても、参考にならなくてもブログを書くようにしている。
何かが違う
ところが、一定の効果があるものの、これを続けてもとてもかずきさんになれるような気がしない。一体何が違うんだろうと長年考えていた。かずきさんのように強力なスピードでコード書けないし、楽しそうじゃないし、ブログもかずきさんのものに比べて薄っぺら感がある。
開眼のきっかけ
私がブログを書いて学ぶときの問題が何であるかが気づいたのは、Udemy の CKA (Kubernetes の 資格取得コース）を勉強している時だった。CKA は、普通の技術系の試験で、単に選択制とかではなくて、本当の kubernetes のクラスタを使って、デバッグしたり、コマンドを叩いたりするのだが、制限時間があるので、それを素早くやれる必要がある。リファレンスを見てもよいのだが、そうすると遅くなるのでどうやったら同じことを早くできるかを考えながら準備する必要があります。このコースでも実際に模擬試験でコマンドを叩きまくります。
このコースを勉強していくうちにふと思ったのですが、「あれ、今の俺って技術イケメンみたいに出来てない？」とふと思いました。
技術イケメンの皆さんと自分の違い
技術イケメンの皆さんを私はいろいろ観察しました。師匠のかずきさん、しばやんさん、ワールドクラスの一流だと思います。そして、同僚で若いのにセンスめっちゃある Roger や、多くの技術に精通する Ahmed、彼を観察して共通することは、技術イケメンの皆さんは、リファレンスすらあまり見ることなく、コードを書いたり、コマンドを叩いたりします。この前 Ahmed とペアプロで、k8s をいじったときは、Docker image のダウンロードが遅いとその場で Dockerfile のイメージサイズを最適化するように書き換えて、速く終わるようにしていました。
プログラミングにしても、インフラいじりにしても彼らで共通しているのは、コードやコマンドの操作を音楽の「キーボード」を弾いているようなノリでダイナミックにコーディングして、オプションの変更とかも自由自在にやって、アドリブで演奏しているかのようです。
自分のイケてなさ
さて、自分はというと、そこそこややこしいプログラムも書くことができますが、そんなにアドリブのようなスピードでコードを書いたり、自由自在にオプションを変更したりできません。リファレンスや、インターネットで調べて、理解して、こうすればよいというやり方がわかったら、それをコードに書きます。だからちゃんと動くし、理解していないわけでもありません。
しかし、何かを変えたら多分もう一度調べないといけません。コードを書くときも、複雑なコードでも、自分の知らないことを調べさえすれば、あまり深く理解していなくても、確実に「動く」コードは書くことができますし、生産性もあまり悪いようには見えません。（早くもないですが）。ですが、技術イケメンの皆さんみたいに自由自在にコードやコマンドを操っている感はなくて、知らないことが出てきたら常に調べているような状態です。
コントロール配下に置いているか？の違い
ここで、CKA のコースの話の戻るのですが、あの練習をやったとき確かに自分は、「自由自在にコマンドを操る感じ」を体感することができました。何が違うのだろうと考えると、自分のゴールを「理解すること」に置くのではなく、「完全にコントロールできている状態にする」ことに置くことでした。
その違いは何か？というと、プログラミングの場合、音楽の演奏と違っていて、「理解」さえすれば、コードを１回書いてしまえば動きます。そして、他の箇所は１回書いた書き方をまねて書けば動作します。ただし、この状態では、技術イケメンの皆さんのように「自由自在にコマンドや構文を操る」ことが出来ません。だから、どうするか？というと「理解」したあとに、「自分のコントロール配下に置く」まで練習するのです。
理解のゴール
具体的に言えば、例えば、Go 言語で、context というコンセプトの理解があいまいだったとします。きっかけはたぶんコードを読んでいて、ここの理解があいまいだなと気づいたのでしょう。理解だけなら、そのコードに書かれている分の意味が分かればOKです。
コントロール配下のゴール
しかし、その構文をコントロール配下に置く場合は、自分が、そのコードを演奏するようにかけなければいけません。どうするか？というと、一旦理解したことを置いておいて、素で何もないところから書けるか試してみます。ただ、１通り書けるのではなくて、コントロール配下を目標します。そうして書いていると、例えば、あれ、context.Background() って使ってるけど、これって他にどんなのあるんだろう？とか、あれ、これって、Valueで値持たせれるけど、どうやって持たせれるんだろう、、、とかあれ、GoLint が文句いってる、なんでやろ？とか、コントロール配下を目標にしたら、いろんなことが見えてきます。
全てのオプションを暗記する必要はないのですが、オプションにも目を通して使いそうなやつは試してみます。試さなくてもわかりそうなやつや、自分が使わなそうなものは、不要です。ただ、自分が完全に理解した状態でゼロから書けるように練習します。だから、何回かゼロから書いてみてもよいです。いったん理解してしまえば、コントロール配下に持っていくまではそんなに頭も使いません。
理解がゴールの時に書いたブログ
さて、ここで、私が全く同じトピックに関して、「理解」をゴールのした時、「コントロール」をゴールのした時のブログをシェアします。
コントロールをゴールにしたときのブログ
全く同じ人間が書いたものですが、物事の掘り下げ方が違うのがわかるかもしれません。なぜかというと、コントロールをゴールにしたら、このコードを本番で使いこなせることがゴールになるので、例えばGoLintで警告がでたら、PRが通りません。だから、気になって調べてしまいます。
まとめ
上記のような方法で、「コントロール配下に置くこと」をゴールにするようになってから、１つ１つのコマンドや、構文が自分があこがれていた技術イケメンの皆さんのように、自由自在にリファレンスも見なくて書けるようになりました。もちろん忘れたりすると思いますが、それでも、一旦「コントロール配下」に置いたものは思い出すのも早いと思います。
この理屈でいくと、私の今の知識は中途半端なものばかりで、コントロール配下をゴールにしたら、ギターの弾き方を変えた時のようにマイグレーションに半年以上かかると思います。ところが、それを過ぎると、少しづつあこがれた技術イケメンのみなさんのように「コードを演奏する」ようにコードがかけるのではと期待しています。