See the Elephant

1992生まれのプログラマが書くエンジニアブログ

t_wadaさんから講演を受けた "新卒に向けたエンジニアの生存戦略"

新卒に向けたエンジニアの生存戦略

TL;DR

プログラマとして生き続けていくということは学び続ける姿勢が必要
自分の学び方をカスタマイズして学び方をハックしていく

このエントリを書くに至った理由

弊社で@t_wadaさんが"新卒エンジニアに向けた生存戦略"と題して講演会を行っていただいた. (@t_wadaさんは弊社の技術アドバイザーとして出社している)
https://twitter.com/t_wada

t_wadaさんの遍歴

大学在学中から設定とプログラミングのアルバイトを始める
卒業後プログラマとしてキャリアを開始
電子政府住基ネットのサブプロジェクトでリードエンジニア
色々あって流しのペアプロ業をやる
プログラマが知るべき97のこと」, 「SQLアンチパターン」の監訳者

はじめに

プログラマが知るべき97のこと, 達人プログラマを背骨にして話していく

一番伝えたいこと : 学び続ける姿勢

  • 常にあなたの知識ポートフォリオに投資すること
  • 技術を学ぶのではなく、技術の学び方を学ぶ
  • 歳をとるとやることが多くなっていくので、技術を早く学ぶ技術が必要になってくる

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

  • はじめのうちは簡単に思える
  • 読むべき本は最初のうちはいっぱいあるように感じる
    • 段々と同じような内容の本になり読む本を選ぶことが難しくなっていく
  • 最初の1,2冊はオススメされた本を読む
  • 次はその本が参考にした書籍を読む

学びの仕組み

  • 感覚記憶 0.5~2.0sec
  • 短期記憶 15~30sec
  • 長期記憶 死ぬまで? storeされているが到達できないのでないと同等になる

脳内インデックスを作る(長期記憶に紐づけるために)

  • なんども引き出すこと
  • 他のものとくっつける(連想記憶)

例えば読んだ本を時系列に並べて考えてみる

  • リファクタリング, TDD, migrationという変遷を経てrailsが登場した

    • リファクタリングの概念を元にTDDという思想が生まれた
    • DBの管理をmigrationというバージョン管理のような仕組みで行う考え方が生まれた
    • それらを実際に実装したWeb FWがRuby on Rails
  • 何らかの技術を説明する際に, その技術が元にしている書籍がある.

  • 時系列に並べる, 読むことで, 技術の流れや成り立ちが体系的に理解出来る
  • 時系列に並べる, 読むことで, 「この本が発刊された時点で今考えられている〇〇という思想, 技術は知る由がない」ということがわかる.
  • そうすると本が出版された時点では存在しない概念を差っ引いて考えることができる

2.手を動かしてやってみる

  • “やる-> できる -> 好きになる"のサイクルを生み出してく
  • 上達の鍵はとにかくまず始める

デールの円錐 http://www.hi-ho.ne.jp/tgoto/medic3/cone%20of%20learning.jpg

発話して手で実際にやる, と9割を記憶できる 写経 : 技術書に書いてあるサンプルコードを写して実行する

  • 写経はかなり深い本の読み方
  • 実際に試しながら読むことで身につく

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

  • はじめは仕事に必要な技術,言語の勉強
  • オブジェクト志向言語のみを扱っているならば関数型を
  • 動的型付きのみを扱っているならば静的型付き言語を

というふうに慣れているパラダイムと異なるパラダイムを触って見る.
こうすることで自分のポートフォリオを広くしていくことが出来る

技術者と英語について

"英語ができるようになるというのは、「大きな図書館の鍵」を渡されるようなものです。1人ひとりの人生にいろんな可能性を与えてくれます” 高松珠子 kwsk : http://lite.blogos.com/article/85541/

プログラマとして生きていくためには少なくともあと数年は英語に触れると諦めること

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

  • 段々と勉強する, プログラミングの対象とするものが減っていく
  • 子供が生まれてからwebカムと携帯を使った遠隔カメラソフトを作っている

そこでプログラマらしく本を書いた(プログラマが知るべき97のこと)

  • 怠惰、傲慢、短気を美徳とする
  • プレーンテキストを好む
  • すべてをバージョン管理する
  • すべてを自動化する
  • 変化を抱擁する
  • 原稿はmarkdown形式
    • 当時はあまりやられていなかった
  • 原文はスクレイピングして取得
    • 書籍界はpdfから原文をコピーすることが多い
    • 制御文字や欠損が多いので不便
    • 原文がwebに公開されているため
  • git を使いバージョン管理
  • 編集者とのやり取りは全て自作サイト上で管理
  • herokuにpushしてサイトに反映
  • 監修差分はdocdiffで表示

結果として手戻りがとても減った

5. アウトプットを行う

量は質に転化する

ある有名な論文を紹介していた.

 * 陶芸クラスの評価を2つ用意.  
 * 質のみで評価する/量のみで評価するグループを作った
 * 結果, 量が多いグループから質が良いものが生み出されていた
 * アウトプットの量を行うことでフィードバックサイクルを早くする
 * 結果として量が質に転化する

量をこなしている人の方が, 一世一代で1つを生み出す人よりも良いものが出せる

アウトプットのチャネル

twitter, blog, 雑誌記事, 書籍, 講演, ライブコーディング, github

blogを書くことがプログラマとしての基本姿勢になる ストック型なので蓄積されていく

新人のよくある質問

Q: 先人が書いているのに僕が書く必要があるのか "情報発信、blog, 発表, 公開などは, 数学の未解決問題の証明ではなく料理のようなものである"

A: 5年前の著名なブログエントリよりも昨日書かれたブログエントリの方が信頼性が高い, と判断される場合もたかい(いつ動いたのかという状態のエントリも価値がある)

紙媒体 執筆する まずは雑誌から初めて見る

何らかの文章のアウトプット(ブログ, 講演)を見て編集者がアクセスしてくる そして, 執筆依頼が来る

雑誌と書籍は全然違う 雑誌は短距離走. 書籍はマラソンなのでモチベーション, タイムマネジメントが必要になって来る

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

1. 生活習慣を変える

あの Jon Resig(jQuery作者)でもうまくいかないこと

週末に自分のプロダクト開発を頑張ろうとしたが失敗 平時と同じ馬力で書けない

  1. 毎日コードを書くこと
  2. 意味のあるコードを書くこと(リファクタリングもカウントしない)
  3. 深夜24時前に終わらせること
  4. 書いたコードをgithubで全てOSSにすること

起こった変化

  • 必要最小限のコードへの集中
  • 30分~1時間で意味のあるコードをかくことが強いられる
  • プログラミングの習慣化
  • githubに草を生やすのが目的ではない. 自分で自分のために生活習慣を帰る
  • 不安との戦い
  • 進んでいる感覚がプロダクトの進捗と同等に大切だと知った

  • 週末の過ごし方

  • 週末はそれほど重要でなくなりリアルライフを充実できるようになった バックグラウンド処理 散歩中やシャワー中に常にコードのことを考えるようになった

  • ワークライフバランス 仕事/生活/自分のプロジェクトのバランスの取り方がわかったのが最大の収穫だった

  • まわりからの理解 毎日コードを書くという習慣を公言したことでパートナーからの理解も得られるようになった

  • どれだけコードを書いたか この習慣を続けると書くコードやアウトプットは自分でも覚えられないくらい生まれる

t_wadaさんが上に追加して行っていること

住む場所を工夫する

  • 始発駅の近くにする
  • 通勤時間は累積で考えると膨大な時間になる

意図的にオフラインの環境を作る -> 捗る

2. 年下から学ぶ

一生プログラマーでいられるかどうかは言い換えれば年下から学べるか否か 年関係なく若い人たちと競える場にいく

できる->好きになる(好きすぎる世界から逃れられない)というサイクルは過剰適用とタコツボ化を生み出す. ベテランはやってきたこと/得意なことにとらわれてロックインされてしまうことがある

タコツボ化の対策として….

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

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

10年前に戦えていた道具が今も使えるとは言えない 意識的に使わないようにしていく

過去から未来を知る

技術は「振り子」と言われるが「螺旋」に似た構造.
同じようなパラダイムが繰り返されている.
10,15年の歴史を伴って同じようなパラダイムが改善されていっている

  • 同じように見えて実はメリットが増えている
  • 同じものとして「わしらもそれで失敗した」と言い始めると老害

ベテランはこの周期を知っている. これが 若手との絶対的な違い

ベテランは前の技術との差分を見ることで限界(未来)を見据えることができる

エンジニアとして価値を下げないために

T字型のスキルではなく複数の柱を作る

  • 他の人に負けないスキルを持つ(尖った技術)
    • これはキャリアの初期には大切なこと
  • 20年くらいやっていると地殻変動が起きる
    • そもそも無意味になってしまうことがある
    • 技術的な柱を持つにも, 枯れ具合が違ったものを持っておく

人の作る渦を見る

githubによってソフト開発は組織->個人へ 個が多く集まると何かが起こる - 大量のゴミを集めることで中から金が見つかることもある

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

  • これまでは大きいベンダが技術の道筋を立てていた
  • appleがやってるのは明らかにロードマップ志向プラットフォーム(これは社員の呟き

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

エコシステムの中心部がレッドオーシャンで周辺ぶんんい生き残りが容易なブルーオーシャンがある

普通の人は,ロードマップでは真ん中, エコシステムの中では真ん中で避けるべき

まとめ

プログラマとして生き続けていくということは学び続ける姿勢が必要 自分の学び方をカスタマイズして学び方をハックしていく

誇りあるプロになってください