【和田卓人氏特別講演】若手エンジニアに送る、"心構え"と"キャリア観" に行ってきた
どんなイベント?
本日(2018/11/10)開催された、サポーターズCoLabさんが主催の、和田卓人(t-wada)氏の講演会です。
supporterzcolab.com
講演会概要
前半:技術を学ぶのではなく、学び方を学ぶ
後半:現役プログラマでいるために
t-wada氏が監修していらっしゃる、きのこ本(『プログラマが知るべき97のこと』)と、きのこ本のエッセイで一番参照されているらしい『達人プログラマー 職人から名匠への道』をベースにしたご講演でした。
books.rakuten.co.jp
books.rakuten.co.jp
今回の資料ではないですが、前回似たようなお話をリクルートテクノロジーズの新人研修でされたそうです。
エンジニアとしてこの先生きのこるために - Speaker Deck
学んだこと【前半】
1. 四半期ごとに技術書をよむ
最初これを聞いたとき、今はできてもこの先ずっと続けていくのは根気がいりそうだなと感じました。
長期記憶は死ぬまで残るらしいですが、人はどうしても忘れてしまいます。
そのためにどうしたらいいかというお話ですが、
・インデックスを作る
・連想記憶を育てる
の2点を心がけるといいそうです。
一番印象に残ったお話は、技術書を読んでいく上で、たとえば、時系列に並べてみるということです。
【メリット】
・本の誤読、課題評価、誤読を防げる
・ソフトウェアと本の時系列もマージしてみる、さらに連想記憶を強化できる
今までやったことがなかったので、気にしてみようと思いました!
2. 手を動かして学ぶ
デールの円錐
よく言われる話ではありますが、デールの円錐のお話をきいて、すごく腑に落ちました。
デールの円錐:
何かを行った2週間後に人はどのくらいの割合でものを覚えてるか?
というのを表している円錐で、割合は以下のようになっています。
受動的:読む10%、聞く20%、見る30%、聞く&見る50%
能動的:話す70%、話す&行う90%
能動的に学ぶ方が多くを覚えていられるのでいいですよね!
デールの円錐については、以下の記事が簡潔にまとまっていました。
http://www.hi-ho.ne.jp/tgoto/medic3/1253.html
写経
t-wada氏がtwitterに書いている写経の仕方を、真似したいと思いました。
技術書の「写経」の方法。 1.ローカルで使える SCM を用意 2.「ほんたった」などで対象の本を固定 3.ひたすらサンプルコードを写して実行 4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む 6.章ごとにタグを打つ
— Takuto Wada (@t_wada) February 12, 2010
技術書読むとき、サンプルコード動かしたりはしますが、あまり写経しながら確認してというところまでは私自身はできてないので、その手の技術書を読むときはやってみようと思います。
3. 毎年少なくとも1つの言語を学習する
ハードル高いと感じますが、
まずは仕事関係の言語、
その後は違うパラダイムの言語を学ぶ、
とするとやりやすいとのことです。
一気に変えずに一つずつ変えていくのがポイントです。
どの言語を学ぶか迷ったときに参考にできるものとして、以下のサイトを紹介していました。
www.thoughtworks.com
4. 身の回りをプログラミング対象にする
家族内のサービスとかでもOK
5. アウトプットを行う
まずは社内勉強会、有志の勉強会
少しずつ執筆の幅を広げていく
ブログ→技術同人誌→雑誌記事→商業出版
ライブコーディングがおすすめ
量は質に転化する
例として、挙げられていた話が以下リンクに
質より量に学ぶ - Radium Software
学んだこと【後半】
1. 毎日コードを書く
紹介されていたサイト
John Resig - Write Code Every Day
毎日コードを書くことのメリット
メリット | メモ |
---|---|
必要最小限のコードへの集中 | 一日30分〜1時間で意味のあるコードを書くことが強いられる。 |
プログラミングへの習慣化 | githubに草を生やすのは目的ではない。自分で自分自身のために生活習慣を変えるのが大事。 |
不安との戦い | |
週末の過ごし方 | 自己プロダクトを週末だけにやってたのが毎日になって余裕ができてリアルライフが充実。 |
バックグラウンド処理 | 散歩中、シャワー中常にコードのことをバックグラウンドで考えるようになって、良いアイデアが浮かぶようになる。 |
コンテクストスイッチ | 毎日だとそんなにない。 |
ワークライフバランス | 毎日やるということは、バランスを取るということ。仕事、生活、自分のプロジェクト |
まわりからの理解 | 「毎日コードを書く」という習慣を公言して、パートナーの理解を得られるようになる。 |
どれだけコードを書いたか | アウトプットの量は膨大になる。充実感を得られる。目的ではないけど。 |
2. 年下から学ぶ
- ベンチマークとアンラーニング
- 定期的に自分のスキルを棚卸しする
- 積極的に外部に出て、自分のスキルを相対化する
- 使う道具を定期的に変える
- 道のコミュニティに参加する
- 若者に習う
- 若者と同じ土俵で競う
ペアプロは良い!!
3. 過去から未来を見る
技術は「らせん」
1周してなぜそこに戻ってきたのか、差分を説明できることがベテランの強み
なんで似た技術が戻ってきたのか?なにが決定的に違うのか?
デブサミでのt-wada氏の講演スライド
技術選定の審美眼 / Understanding the Spiral of Technologies - Speaker Deck
4. 人の作る渦を見る
組織から個の時代へ!
5. 大事なことに集中する
実践しようと思ったこと
一気に全部始められる気がしないので、今すぐ始めようと思うことにしぼります。
・四半期ごとに技術書を読む、手を動かして学ぶ
→読んではいるけど、写経はあまりしないので、するようにしたい
・アウトプット
このブログ、まだ3記事目(実質2記事目)なのでブログ記事書いてていきたい
放置しているQiitaやGitHubも活用していきたい
さいごに
本講演の内容の大部分が、私自身がまだまだ実践できていないと感じるものだったので、早速徐々に実践していきたいです!
どうしたらいいのか、何故良いのかといったお話が盛りだくさんでしたので、モチベーションも上がりましたし、実践のハードルも少し下がったように感じます。