Pocket

@shi3z　 さんのブログ「若人へ 」を読んで、正直、鳥肌がたちました。

「雰囲気イケメン」は、なんとなくすごそうに見えているだけ（私が暫定的につけました）の例えです。

実体験も含め、プログラマとして将来、雰囲気イケメンになってしまうかもしれない、危ういアンチパターンをまとめました。

「雰囲気イケメン」とは

なんかこの人すごそう、経歴をみるとすごそうなことやってきた人っぽい、とかそんな雰囲気が漂っているだけの人です。

この人は、他人にもすごそうと思わせていますが、自分はすごい的な勘違いをしています。

@shi3z さんはこれをブログにて「危うい」と書かれています。

若いうちは、何かをしようとしただけでちやほやされる。
けど、それは君がなにか凄い人間だからじゃない。若い人にはみんな期待したがるんだ。(「若人へ」より)

確かに、何かを成し遂げた経験が過去にあると、それを全面に押し出したくなりますが、それは本当に自分のチカラなのか？

例えば、ワールドカップで優勝したチームの一員だとします。
この事実は確かにすごいですが、
「ワールドカップで優勝したチームの一員でした」っていうとすごそうな雰囲気がしますが、実は「チームメンバーとしてベンチをあたためていました」というのでは雰囲気イケメンです。
(※チームプレイを否定しているわけではなく、あくまで大げさな例です)

自分の力が直接的に勝利に繋がっていて、再現性があるのかというのが、本人自身のすごさであって、本質的に意味があることではないでしょうか。

有名大学に受かった大学生が、「◯◯大学のXXです」みたいにそれだけ押し出してドヤってるのも同じようなものです。

…

そんなことがプログラマとしてもあると思います。

①ライブラリを何となく使っている

ライブラリの仕様を読まないパターンです。

「〇〇というコード→XXXができる」という表面上のできることだけ確認して、なんとなく使えてしまいます。

ライブラリを使うといろんなことができて、すごくなった気分になります。

が、

ライブラリを使っていいモノがつくれたとして、ただそれだけで満足してたら雰囲気イケメンになりかねない。
この場合本当にイケメンなのはライブラリつくったひとです。

最低限、イケメンの書いてくれたREADMEは目を通して、ライブラリの実現したい全体像は掴んでから使いたいものです。

②ググったままのソースコードをコピペ

ググって出てきた、サンプルコードのマネをして、そのまま盛り込んでしまうパターンです。

サンプルコードはあくまでサンプル。人に説明するために簡素化していたり、そもそも変なコード書いている人もいるので、自分で理解して、自分のコードとして書くことが必要。

サンプルコードの意図を理解してから、適用したいところに最適化して使いたいです。

③憶測でバグフィックスをしようとする

実装していたら、エラーやバグが発生します。

エディタやブラウザ、ログなど様々な手がかりをツールが提供してくれているにも関わらず、前にもこんなことあったからたぶんココを修正すればいい、という安易な憶測で対処する人がいます。

「前にもこんなことあったから」というときには、偶然プログラムが動くようになっただけなのかもしれない。

根本原因の切り分けをして、ひとつひとつ対処していくことが大切。

④「後で読む」

なんかブックマークしただけで、なんとなく満足してしまうあれです。

そう思っても結局読まずに溜まっていきます。

溜めたものをまとめて読む時間を習慣化したいものです。

⑤チームの中に埋もれてしまう

チームで開発をしていると、客観的な評価がチームとしての評価になることがあります。

冒頭のサッカーの例でもそうですが、チームとして好評価だった場合、そこに自分がどれだけバリューを提供しているかを考えるべきです。

逆に、チームとして悪い評価だったとき、「チームの責任だから」で終らせるのではなく、問題の根本原因を探るべきです。

まとめ

今思えば当たり前のことな気がしていますが、改めて振返るきっかけになりました。

若いうちは、雰囲気イケメンだとしても、勘違いをした状態で歳とったら実体はイケメンでもなんでもないので、ただのオッサンです。

地に足着いてないオッサンにならないために、明日からもがんばります。