【和田卓人氏特別講演】若手エンジニアに送る、"心構え"と"キャリア観" に行ってきた

【和田卓人氏特別講演】若手エンジニアに送る、”心構え”と”キャリア観” にいってきたので個人的なまとめです。

ちなみに講演の裏テーマは、こちらの書籍です.


@t_wada さんのキャリア

  • 大学在学中の設計とプログラミングのアルバイトがきっかけ.
  • 卒業後はプログラマとしてキャリアをスタート.
  • 数千人規模プロジェクトのリードプログラマからメンバー4人のアジャイルまで.
  • 現在は講演, 執筆, OSS活動などなど.

かの有名なライオンは @furukawa_yosuke さん作だと初めて知りました.

技術を学ぶのではなく、技術の “学び方を学ぶ”

四半期ごとに技術書を読む

人間の頭のストレージ

  • 感覚記憶 -> 0.5-2sec フラッシュメモリみたいなもの
  • 短期記憶 -> 15-20sec
  • 長期記憶 -> 命尽きるまで(諸説あり)

長期記憶があるはずなのに忘れていることが多い.
-> 脳内インデックスを作る.

  • 記憶から情報を取ってくる picker を育てる.
    長期記憶から情報を取り出してくる反復練習を行う。

  • “荷物” を他の “荷物” とくっつける.
    連想記憶を育てる.

技術書は、他の技術書を参考に執筆されている.
-> 紐づく過去の書籍をたどっていくことで理解を深めることができる.

手を動かして学ぶ

やる -> できる <--> 好きになる

“できるようになってからやる” タイミングはなかなか来ない.
“やろうと思ったときが始めどき”.

# keyword
デールの円錐
https://en.wikipedia.org/wiki/Edgar_Dale#Cone_of_Experience

視覚情報だけでなく聴覚(会話)や触覚(手を動かす)
-> ここでも反復練習
-> ある程度やったらレールを外れてアレンジしてみる

ex.

  • 写経

毎年少なくとも1つの言語を学習する

若手は、仕事で使うプログラミング言語を徹底的に学ぶ、マスターする.
次は、仕事には関係ないかもしれないパラダイム(動的/静的型付け、関数型/オブジェクト指向)の言語を学ぶ.

新しい言語は、当然過去の反省を踏まえて作られている.
例えば TECHNOLOGY RADAR で動向を抑えておく.

ゴールは “自分のプログラムが実際に使われている(OSSでも家でも)” 状態.

言語といえば “英語”
-> “読む”ことができるだけで得られる情報の質/量が格段に上がる.

身の周りをプログラミング対象にする

“仕事で必要になる言語” と “学習したい言語” は得てして乖離する.
-> 身の周りのちょっとしたイライラをシステム化してしまう.
-> t_wada さんはきのこ本の校閲中にメールとワードでのやり取りに煩わしさを感じ、ツールを作成した.

アウトプットを行う

“何かをマスターしたければ、それを教えることである”

量は質に転嫁する

  • インプットとアウトプットをひたすらサイクルする.
  • 傑作だろうが駄作だろうが、思考して手を動かすサイクルを回した量が、質に影響する.

Blog を書く

情報発信, blog, 発表, 公開, などは数学の(未解決問題の)証明ではなく、料理のようなもの
by Jenkins開発者 川口氏 
  • すでに実践されたことでもプラットフォームが変わるなどして動かない、ということはよくある.
  • 苦戦した、エラーが発生したなどの “ハマり情報” は世の開発者の役に立つことが多い.

コードを公開する

  • t_wada さんの代表作は power-assert.
    -> コード書きについては、後ほど詳細.

講演する

  • できればライブコーディングをするとインパクトが強い
    -> ただしハイリスク・ハイリターン.
    -> ライブコーディングをするには準備と度胸が必要.

現役プログラマでいるために

毎日コードを書く Write Code Every Day

jQuery 作者 John Resig が週末に自分のプロダクト開発を頑張ろうとしたが失敗.
-> 4つのルールを自分に課した.

  1. 毎日コードを書くこと.
  2. 意味のあるコードを書くこと.
  3. 深夜24時前に終わらせること.
  4. 書いたコードをGitHubですべてOSSにすること.

その結果、こんな効果が得られた.

  • 必要最小限のコードへの集中
    -> 1日30-60分程度で、”意味のあるコード” を書くことを強いられる.
    -> ブログやリファクタリングは含まない(これはハードルが高いので人によって調整)

  • プログラミングの習慣化
    -> 結果としてGitHubに草が生える

  • 不安との戦い
    -> “進んでいる” という実感を得ることができた.

  • 週末の過ごし方
    -> 週末やっていたことを毎日やっているので、リアルライフが充実した.

  • バックグランド処理
    -> 散歩中、シャワー中でも常にコードのことを考えるようになり、良いアイディアが浮かぶようになった.

  • コンテクストスイッチ
    -> 毎日やっているので、気持ちを切り替えるコストがなくなった

  • ワークライフバランス
    -> 毎日続けるために無理のない生活バランスを見つけることができた.

  • 周りからの理解
    -> “毎日やる” と公言したことで、家族、パートナーからの理解が得られた.

  • どれだけコードを書いたか
    -> 毎日やると膨大なアウトプット量になり、充実感を得られる

t_wada さんの工夫

  • 始発駅の近くに住む
    -> 始発だと座ることができる.
    -> 通勤の1時間座ることができればコードが書ける. 帰りはインプットの時間にする.
    -> 意図的にオフラインの時間を作る.

年下から学ぶ

  • 一生プログラマーでいれるかどうかは、言い換えれば年下から学べるか否か.
  • 定期的に自分のスキルを棚卸しする.
  • 積極的に外部に出て、自分のスキルを相対化する.

ペアプロをやると、ツールなどへのこだわりも知ることができる.

過去から未来を見る

  • 技術は “振り子” ではなく “螺旋”
    -> 上から見ると行ったり来たり. でも横から見る差分がある. この差分が重要.
    • なぜその場所に戻ってきたのか
    • なにが変わって戻ってきたのか

-> 差分を身を持って説明できるのが、ベテランエンジニアのアドバンテージ.

技術選定の審美眼

  • T字型で一本の柱ではなく、複数の柱を持つ.
    -> “~ならこの人! だけどこんなこともできる!”
    -> t_wada さんの場合は、テスト駆動開発も RDB も RESTful も.

人の作る渦を見る

  • 組織の時代から個人の時代へ
    -> 個が多く集まると何かが起こる
    -> 玉石混交だが社会的にはその中の玉が見つかれば恩恵が受けられる
    -> GitHub の登場がこれを推進した.

  • ロードマップ志向からエコシステム志向へ

  • Worth is Better

本当に必要なことに集中する

エッセンシャル思考

ライフイベント(結婚したり子供ができる)と自分の時間は間違いなく減る.
-> 若いときが、柱を作るための頑張り時.


前に行ったMatz氏の講演と重なる部分もあり、アウトプットを継続していくことの重要性を改めて認識しました.
【まつもとゆきひろ氏 特別講演】20代エンジニアのためのプログラマー勉強法 に行ってきた

自分としては趣味で作ったものを社内LT大会で発表したりしていましたが
最終的にブログやGitHubに集約していきたいです.