いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。
自分が使う道具を厳選して選んで手入れをしている
エンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。
厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。
1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。
2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への対応などを自ら拡張してエディタやツールからサポートとフィードバックを受けること。
エディタやツールは道具でもあって、一緒に戦うパートナーでもある。
他人のコードを読む習慣がある
コードの悪い部分をいう回数よりも圧倒的に良い部分をいう回数の方が多い。よって、「なんとなくキモイ」という見解で終わるのではなく、過去の知識から「何をどうするともっとよい」と具体的に指摘や提案ができる。
自分が書いたコードにも同じアプローチを実践できている。そして、つねにもっと良い方法は？と貪欲である。
まず自分を疑う
新技術などに対して、うわべだけの知識で批判したりなどはしない。なぜこれまでに提唱され皆に使われているのか自分が知らないだけだということを前提に理解しようと努力する。その上での比較結果を述べることはある。手を動かして、理解して、何事も自分のものにして、経験に変換した上で述べるのである。
本当に大切なことから着手する
実装が終わらないとリリースできない機能よりも、着手しやすい機能から実装して、肝心なところを後回しにすることなどはしない。リソースは有限であり、優先度は常に変動する。
リリースできない致命的な状態よりも、リリースできるが小さな問題や修正ポイントを抱えている状態が良いことを理解している。そして、バグのない究極のソフトウェアや誰もが絶対に満足するソフトウェアは絶対につくることができないことをよく知っているのだ。
憶測しない。計測、証明する。
むやみにボトルネックは○○だろうなどといわない。計測して、証明をする。
原因の見えない問題に対して、意味のない論議に時間を使うことよりも、原因を探ることの方が前に進むことを知っている。
ゴールを設定してからはじめる
本当に必要なのだろうか？それを得た状態はどういった状態か？どんな効果をもたらすのか？明確にした上ではじめる。
思いつきのプロトタイプや、何となくではじめたものは莫大な時間の浪費であり、実は得られるものが少ない。もしくは皆無であることが多い。
それは、なに？と素直に聞ける
知ったかぶりなどはしない。使った経験がないが、どういったものなのか？と聞くことができる。
自分と相手の経験と知識は違うものであり、お互いの観点から適切な判断や論議ができる。また、自分が知らないことに対して興味を持つきっかけになる。
まとまった時間をかけて何かを深く掘り下げる
必要な物事に対してまとまった時間を確保して深く掘り下げることをしている。
自分が何を知らないのか認識した状態だからこそ何を知るべきで、何を掘り下げて学ぶべきなのかを理解しているから。
そして、まとまった時間を投資することが効率的であることも理解しているし、何よりそれが楽しいことである。
情報発信をすることができる
低レベルなことでも高レベルなことでも相手のためになる情報を簡素に提供している。
本質的な情報発信や提唱をしていれば「あの人の意見は耳を傾ける必要がある」と一目置かれ、深い論議をしている。
関連記事
自警の意を込めて、以下を後日書きました。
仕事の効率を高めたい人向けの記事はこちら
スーパーエンジニアに近づくための過去記事
- 達人プログラマーに学ぶ リファクタリング
- 達人プログラマーに学ぶ 品質とチームメンバーの役割
- 達人プログラマーに学ぶ 絶え間ない結合化と容赦ないテスト
- 達人プログラマーに学ぶ どこでも自動化
- 達人プログラマーに学ぶ コメントは必要？不要？
 |
アンドリュー ハント、デビッド トーマス、Andrew Hunt、David Thomas、村上 雅章 |
