元税理士受験生、プログラミングをする

1990年生まれド文系プログラマーの軌跡(元名は今日もエメラルド気分)

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

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

supporterzcolab.com

もう一ヶ月以上も前だが、t_wadaさんの講演会に行ってきた。

今更ながら、メモが発掘されたが、意外とよくまとまっていたので折角なのでブログに記した方が良い。

テーマは「学習方法のHowTo」

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

読書

技術書をリニア(速読)せずに読んで行くのはよくない。

技術書の読み方は、複数冊読んで、差分を抽出して読む。

徳丸先生も、「新しい技術は既存技術の差分として習得する」ことがベストプラクティスとしている。

記憶の分類は3つある。

  • 感覚記憶
  • 短期記憶
  • 長期記憶

1.脳内インデックスを作る

記憶のピッカーを育てる = 反復練習

短期記憶を複数回実行 -> 長期記憶へと昇華

読書は時系列に読む。

つまり、書籍同士のリレーション関係をみる(参照書籍etc...)

ここではRailsを例に出して説明している。

Railsは2004年に出てきて、Webアプリケーションの作り方が大きく異なる。

このイベントの前後では、書籍の背景が違うので損得(Railsの取捨選択)を考えて読む。

Rails開発者のDHHについても言及されている。

Railsは、2004年以前のまだ未実現のRDBのベストプラクティス(migrationによるRDB管理)を盛り込んでいる。

つまりは、Rails誕生の2004年以前のベストプラクティスのどこまでをRails自体に盛り込まれているか。

逆に盛り込まれていないものに対しては、何故なのか。背景を理解する。

2.実際に手を動かしてアウトプットをつくる

デールの円錐

www.ladea.jp

  • 読んだだけ 2週間後は、10%覚えている
  • 読んだだけ+耳から聞く 20%覚えている
  • 読んだ+聞いた+見た 30%覚えている
  • 読んだ+聞いた+ロケーションを見た+デモンストレーションを見た 50%
  • 上記+相手に話す 70%
  • 上記 + やってみる 90%

スピードが落ちるが、習熟度がグッと上がる。

上記のtweetについても言及

写経するだけではなく、疑問点があったらコミットログや本に書き込む。

書籍を能動的に読む。

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

学習する言語にテーマ性を持たせる。

  • 仕事で使っている言語をマスターする。 -- 流行りの言語 -- thechnology radarを参照して、ADOPT(実践) - TRIAL(挑戦的) - ASSESS(視界には入れておく) - HOLD(やめておけ)の順で優先順位を決める

自分がrubyプログラマーだとする。

haskellのような構造が全く違う言語は、酸欠になりやすい。

かといってrubyと似ている言語だと学びが浅い。

rubyの場合、動的型付、スクリプト言語である。

つまり静的型付、関数型だと学びか多い。

このように選択する。

技術書と英語について

英語ができれば今は有利

将来は英語ができることがスタンダートになる。

英語ができるようになるというのは、「大きな図書館の鍵」を渡されるようなものです。

一人ひとりの人生にいろんな可能性を与えてくれます。

4.身の回りをプログラミング対象にする

例としては、和田さんの翻訳作業

5.アウトプットを行う

このプレゼンも毎回アップデートしている。

かつ、質問を受けてインプットも受けている。

量は質を転化する

プログラミングは量をこなすこと。

アウトプットのチャネル

  • twitter
  • blog,Qiita
  • 雑誌記事(Web,紙媒体,電子媒体)
  • 書籍(共著,翻訳,監修,単著)
  • 講演(社内勉強会)

プログを書くのは、最も軸にしてほしい

しかし、ブログは未解決情報ではないので、公開に至らず。。。

情報発信、blog、発表、公開などは、数学の未解決問題の証明ではなく、料理のようなもの

実際にチャレンジしたことが価値がある。

プログラミングは、環境によって動作が大きく異なるので、5年以上前の良質なエントリーよりも、当日の多少粗悪なエントリーの方が価値があることが多い。

また、良質なエントリーをひたすら更新し続けることも有効

ブログによって良質なアウトプットを続けていると、雑誌の執筆の仕事が入る。

講演する

資料を作成

できればライブコーディングで(印象が最も残りやすい)

  • 壇上ではネットワークが繋がらな
  • ライブコーディング中にものが倒れる

不足の事態になりやすく、それに対する準備する力がつく。

もう一つは和田さんのプログラマーでいるためのHotTO

1.毎日コードを書く

Write Code Every Day

  • 毎日コードを書くこと
  • 意味のあるコードを書くこと
  • 深夜24時前に終わらせる
  • githubで全てOSSにする

その結果の変化

  • 必要最小限のコードへの集中
  • プログラミングの習慣化:githubに草を生やすのが目的ではない
  • 不安との戦い:毎日コードを書いて、進んでいるという実感は実際の進捗と同じように大切だ
  • 週末の過ごし方:週末は平日の延長線になった
  • バックグラウンド処理:散歩中、シャワー中に常にバックグラウンドで考えるようになり、良いアイデアが浮かぶようになった。
  • コンテクストスイッチ:以前は週に一回だったが、毎日やるのでスイッチの変化の必要がない
  • ワークライフバランス:毎日続けるには、やり過ぎてもやらな過ぎてもよくない。適量が大切
  • 周りからの理解:毎日コードを書くと周りからの理解を得られる。
  • どれだけコードを書いたか:この習慣を続けると書くコードやアウトプットは自分でも覚えられないくらいの量になる。

時間を作るためには

住む場所を工夫する。

始発駅に住むと、座ることができる。

2.年下から学ぶ

一生プログラマーでいられるかどうかは、言い換えれば、年下から学べるか否か

好き->できる->好き->できる ->.......

ループすると技術のタコツボ化

ベンチマークとアンラーニング

  • 定期的に自分のスキルの棚卸
  • 積極的に外部に出て、自分のスキルを相対化する
  • 使う道具を定期的に変える
  • 未知のコミュニティに参加する
  • 若者から学ぶ
  • 若者と同じ土俵で学ぶ

一番学びが大きいのは、ベアプログラミング

ベテランにはアンラーニングのチャンス

3.過去から未来をみる

技術は「らせん」

3層アーキテクチャ -> REST(3層とは別物) -> Graphql(2層アーキテクチャ)

ベテランは、削除された1層分は、なぜ削除されたのか理解できる。

これは、ベテランの唯一のアドバンテージ

これを忘れると「老害」となる

「T字型」ではなく複数の話を

これは、T字型は外部の圧力がかかる恐れがある。

つまり、一本折れたら死ぬことを意味する。

複数の柱は、別ベクトルで持つこと。

一つは変化の早い技術

もう一つは枯れた技術

4.人の作る渦にいる

組織の時代から個人の時代へ

github登場から突出した個人が、責任を持ってチームを持つ。

個が多く集まると、イノベーションが加速する。

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

「エコシステム」は熱帯雨林のように、食い合いつつ強制しあう様々なプレイヤーが、自分のためだけの個別の意思決定をして、その相互作用で技術が発展していく。

普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ

例として、「ロードマップ」はAppleの中ではswiftが中心になってる。Object-cで頑張ることは「ロードマップ」の外にいることになる。

エコシステムは下記を参照

www.thoughtworks.com

Worse Is Better(悪い方が良い)

大事なことに集中する

年をとると、どんどん自分の時間に減る。

つまり、何かに選択と集中しなくてはならない。

終わりに

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

質疑応答

Q.何を持って技術を学び終えるのか

A.中級を完了し、アプリケーションかライブラリの公開をする。

つまり書籍から離れて書く。

また、リファレンスを参照せずにコードがそこそこ書けると、マスターした指標になる。

Q.書籍はどこまで遡ればいいのか?

A.20年前まででいい。

それ以前は、技術の作者の書いた本のみを読む。

例として、達人プログラマーの心構えは現役で通用する。

しかし、コード部分は完璧に使えないものになってる。

感想

一番参考になったのは、

ロードマップとエコシステムの思考

である。

自分が使っている技術を省みて、どちらに寄っているか判断して、時間を投資していきたい。

こちらのブログにも私より詳しい感想が書いてあるので、ぜひ

sinnderu.hatenablog.com