あじちゃんのブログ。備忘録。

〜SEもOLなんですかね?

和田卓人(t_wada)さんによる新卒エンジニア向け講演のメモ

🦁 https://twitter.com/t_wada?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor

 

監修、監訳、翻訳した本

 

👀 https://azu.github.io/slide/sakurajs/power-assert.html#/

 

「流しのペアプロ業」

 

  • 達人プログラマー the pragmatic programmer
    • プログラマはどうあるべきか
    • キャリアはどうか 等
    • 20th aniversary edition が発売されますとのこと. 内容は1/3くらい新しい

 

  • 18) 学び続ける姿勢
  • “常にあなたの知識ポートフォリオに投資すること”
    • 競争力がある状態を保つ

 

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

  1. 四半期毎に技術書を読む
    • 反復練習からピッカーを育てる
    • 何度も長期記憶から出し入れする(技術ブログを書く、技術書の内容を要約してみる、他人と話してみる)
    • 連想記憶を育てる(技術史を捉える著者、時系列(原著の出版順)、出版社、表紙 など)

 

    • 書籍から企業ブログの時代へ@2019nenn
      • the netflix texh blog とかそういうリーダー的な企業のブログ

 

  1. 手を動かして学ぶ
    • やるできるすきになる
    • 好きかどうかは後からついてくる。技術に手を出すか出さないか
    • 手を出して深めることで好きになるし成熟していく
    • スキルセットの網が変わってくる(自分の今の思考で考えるよりはどちらに網を広げたいかでどの領域に手を出して行くかが変わってゆく)
    • デールの円錐
      • 2週間後に人間はどれだけのことを覚えていられるか」
      • 発言して行動したことは90%覚えていられる
        • 学んだことをアウトプットしないとほとんど忘れてしまう
    • 写経

```

技術書の「写経」の方法。

1.ローカルで使える SCM を用意

2.ほんたった」などで対象の本を固定

3.ひたすらサンプルコードを写して実行

4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む

6.章ごとにタグを打つ

```

 

  1. 毎年少なくとも1つの言語を学ぶ
    • 結構難しいことです
    • 達人プログラマーで書かれているみんながやり始めて、相互効果を引き起こしていろんな言語同士技術同士の相関を生んだ
    • 最初の何年かは優しい(仕事に使う言語を学ぶから)より洗練された考え方を得られる、アウトプットがよくなり評価が上がる。改善のフィードバック作用が起きる
    • プログラミング言語パラダイム(ものの見方・考え方を支配する認識の枠組み)を少しずつ減らしていく
      • 静的型付けの言語しかやってこなかった人が動的型付けの言語をやるとかそういうやつ(言語を変えながら徐々に移行していく、パラダイムを狭めていく。最終的に正反対のものを習得する
      • 自分のスキルセットの棚卸しになる
      • [technology radar](https://www.thoughtworks.com/radar) などを参考にすると良い

 

        • 参考に日本語の解説@2019年 https://allabout-tech.hatenablog.com/entry/2019/04/24/114300
        • 技術トレンドの分析を Techniques(開発手法) / Tools(ツール) / Platforms (プラットフォーム) / Languages & Frameworks(言語とフレームワーク) 4分野に分けている
        • 評価結果も ADOPT / TRIAL / ASSESS / HOLD4つに分けられています
          • ADOPT : プロジェクトにマッチするならば、採用を強くおすすめしている。
          • TRIAL : プロジェクトでリスクを管理できればやる価値はある。
          • ASSESS: どのような影響をあたえるか理解するために採用するときがある。(今後のために採用するときがある)
          • HOLD : 採用する場合は慎重に進める必要がある。

 

 

技術者と英語について

英語ができるようになるというのは、大きな図書館の鍵を渡されるようなものです。一人一人の人生にいろんな可能性を与えてくれます

  ーー高松珠子

 

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

自分が設計したものを自分でプログラミングする

仕事に止まらなくなった時に、自分の生活をプログラミング対象にする

言語選択は自分がやりたいものをやる

 

例:書籍の執筆をよりやりやすく、プログラマらしく!

    • 怠惰、傲慢、短期
    • プレーンテキストを好む
    • 全てをバージョン管理する
    • 全てを自動化する
    • 変化を抱擁する

    • 原稿はmarkdown形式
    • 原文はスクレイピングして取得
    • gitを使いバージョン管理
    • herokupushしてサイトに反映
    • 監修差分はdocdiffで表示

 

最近作ったもの

などなど

 

怒りの沸点を下げる。小さなイラつきの負荷を下げる。

 

  1. アウトプットする

if you want to master something, teach it. — richard feynman

 

 

    • 量は質に転化するhttps://kzr-2.hatenadiary.org/entry/20080808/p1
    • blogを書く → 技術文章を書く(長い文を書く)
      • フロー型のメディア(twitterとかの過去データが流れてしまうメデイア)
      • ストック型のメディア(ブログとかの過去データにすぐに到達できるメディア)
      • クソエントリ問題 →  “情報発信、blog,発表,公開などは、数学の(未解決問題の)証明ではなく、料理のようなもの”(カワグチさん)ということで、一番最初にやった人が偉いわけではないということ。カジュアルでアレンジしても価値があるものである。気軽に立ち向かっていいもの。
      • 様々な理由、タイミングで様々な問題解決の方法がある。そういうものの試行錯誤の過程を包み隠さず書いてしまう。情報を圧縮しない。そういうものに価値がある。(エラーメッセージを全て書くとか。解決の過程を書くとか。)
      • クソエントリをクソエントリとしない書き方。今のバージョンがなんなのかとか環境がどうなのかとかそういった情報精度を上げていくことが大事
    • 上記のようなアウトプットをし締めて行くと自分自身のブランディングにもなる執筆する、書籍やwebメディアなどへの入り口が開ける

 

    • 技術同人誌市場の誕生
      • 技術書典とか
      • 裾野が広く、且つ商業活動として回せる
      • カジュアル
      • ブログで書き溜めたものを書籍にするのが手堅い

 

    • コードを公開する
      • コツコツやっていればいつか化けることもある
    • 講演する
      • ライトニングトークなど
      • 教えることと同等で講演する時に台本を作ることですごく大事な学びになる
    • ライブコーディング
      • ハイリスク/ハイリターンである
      • みている側の満足度が高い(ライブコーディングできる人は少ないので
      • 普段見ているコードは結果としてのコード(取捨選択されたもの)
      • プログラミングとして大事なのはコミットとコミットの間(何をやり何をやらなかったのか。どんなことを考えながら書いたのか。)
      • 失敗した時の悲しみは大きい
      • 社内のハッカソンとかでライブコーディング経験をつんだりすると良い

 

 

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

  1. 毎日コードを書く

jQuery作者John Resigは週末に自分のプロダクト開発を頑張ろうとしたが、失敗

    • 平日と同じ馬力では書けない
    • 全ての週末が空いているわけではない
    • 1週間は長くコードを忘れてしまう
  • write code every day ( https://johnresig.com/blog/write-code-every-day/ )
    • 毎日コードを書く。ブログドキュメントその他はコードを書いたらやって良い
    • 意味のあるコードを書くこと。インデントやフォーマットの修正可能ならばリファクタリングをコードを書くことに含めない
    • など……

  • 必要最小限のコードへの集中:一日0.51H程度で意味のあるコードを書くことを強いられる
  • プログラミングの習慣化:草を生やすのが目的ではない。生活習慣を変えるのが大事
  • 不安との戦い:以前は十分に進んでいる、十分に完成しているか不安があった、毎日コードを書いてみて進んでいるという実感は実際の進捗と同じくらい重要だという気づきを得た
  • 週末の過ごし方:週末もweekdayも等しい一日になってリアルライフを充実できるようになった
  • バックグラウンド処理:普段の生活の中で常にコードのことをバックグラウンドで考えるようになり、良いアイディアが浮かぶようになった
  • コンテクストスイッチ:以前は週1回の開発だったのでコンテクストスイッチのコストがあったが、いまは毎日なのでそれがない
  • ワークライフバランス:バランスの取り方がわかった。毎日やるということはバランスを取るということ
  • 周りからの理解:「毎日コードを書く」習慣を公言したことでパートナーからの理解も得られるようになった
  • どれだけコードを書いたか:コードやアウトプットは膨大な量になり、充実感につながった

 

 

住む場所の工夫

  • 始発駅の近くに住む(座れる可能性をコントロールする)座れれば自分のインプット/アウトプットの可能性をコントロールできるようになる

 

意図的にオフライン時間を作る

  • twitterとかhatebとかの誘惑を断ち切る
  • 30分とか1時間とかでいい

 

年下から学ぶ

  • “一生プログラマーで入れるかどうかは、言い換えれば年下から学べるか否か”
  • 若者と同じ目線で学べる姿勢・環境を作る
  • 過剰適合とタコツボ化できる←→好きになる 定期的にスキルセットを棚卸し、切り離しをして行く必要がある(痛みを伴う)
  • ベンチマークとアンラーニング
  • 積極的に外部に出て自分のスキルを相対化する
  • 使う道具を定期的に変える
  • 未知のコミュニティに参加する
  • 若者から学ぶ

 

ペアプログラミング:ベテランにはアンラーニングのチャンスになる(教えることは学びになる。知識の再構築。若手が使っている道具をリアルタイムで観察できる)なるべく若手に主導権を渡してコーディングする。ベタなところだとエディタ。

自分が本気で使っているエディタ。それを知らない新しいエディタを本気で使っている人の本気の使い方を知ることはかなり大きい。

無理に慣れ親しんだエディタを離れる必要はない。新しいものを学ぶことが大切

 

  1. 過去から未来を学ぶ

技術は振り子である

技術は螺旋

螺旋の軌跡の差分を理解できることがベテランプログラマの唯一の強み

差分が見えなくなると老害になってしまう

https://speakerdeck.com/twada/understanding-the-spiral-of-technologies

 

 

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

螺旋や振り子の話のように一定周期で大きな変化がおとずれるので、1本柱でやっているとボッキリ折られてしまうことがある。

10年で3本くらいのイメージで作っていくイメージ

近くに3本立ててはダメ。好きなものだけだとダメということ。1本折れると一気に折れてしまう。

 

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

コミット権は与えられるもの → GIitHub → 個人があり公開があり世界が育っていく

オープンソフトの開発が大きく変わる

アウトプットの量が世界的に増えた

個が多く集まると何かが起こる。宝石がある。イノベーションが起きる。

 

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

https://essa.hatenablog.com/entry/20140330/p1

技術選定の話。

“ロードマップが指し示す未来の方向と違う方向に進むことは致命的な間違いだが、エコシステムは中心部がレッドオーシャンで周辺部に生きる残りが容易なブルーオーシャンがある。”

どちらが正しいというわけではない。自分が生きる世界がどちらに注力しているのかを見極めないと死んでしまうよ。

例)iOSアプリ→ロードマップ指向(appleが指し示す)

 

The Rise if “Worse is Better”:http://chasen.org/~daiti-m/text/worse-is-better-ja.html

どっちが筋が良いかとか指示されているかというのはもっと俯瞰的に見なければならない

NPCO(とりあえず作って出せば良いという考え方)の免罪符ではない。

「設計の正しさと実装の美しさが両立できない・対立する時、実装の単純さを保った方が目の前の問題を解決し、開発参加のハードルが下がるので進化的な強さを獲得することができる。」というもの

技術の重点をどこに置くのか

 

  1. 大事なことに集中する

ライフステージによって時間の使い方が変わる

エッセンシャル思考:https://www.amazon.co.jp/dp/4761270438/ref=cm_sw_r_tw_dp_U_x_TKn7CbN4X9VW7

 

 

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

 

QAタイム

Q. 自分の技術を少しずつ広げて行く話。他にありますか?

A.

  • 無目的でパラダイムの違うものを広げて行く方法
  • 分野を獲得して行く方法
  • カテゴライズして軸を与えることで戦略を立てていける
  • 古典言語を学ぶと全然違うのでやってみるといい:後の言語に何が引き継がれ何が捨てられたのかが紐解ける。プログラマーとしての思考を広げることができる

 

Q. 仕事中に自分のプロジェクトがちらつくのはどうしたら?

A. 仕事をやっている時に自分のプロジェクトの解決策が思いつくとかよくある。メモっておくとかイシュー積んだり通らないテスト書いたり。仕事に影響が出ない程度に自分のプロジェクトをやって良いと思う。信頼を身につけておくことが大切。許可を得るより後で謝った方が楽。がっつりやらずにやる。相互作用を与えてくれるので。

 

Q. ベテランとは?どのくらいのことを指す?

A. 仕事としてプログラミングをやっている年数でいうと15年とか。あんまり考えてなかった。生活環境が変わってくるぐらいの年齢。

 

Q. 毎日コードを書くこと。24時前に終わらせるのはなぜ?

A. 継続性を大事にする。規則正しく行うということ。一日のカウントがどこかという話。

 

Q. アウトプットとは

A. 生活の身の回りをコーディングするにあたって。対外的に成果物を出すのがアウトプット。自分が学びたい設計とかアーキテクチャをいれてやる。だいたいやりすぎる。自分だけが痛い目を見て学べるので低コスト。こうやるとどうなるというのを自分で見守ることができる。学ぶ要素は言語に限らないよ。

 

Q. 軸にする学ぶものは散らすようにすることについて。散らす範囲をどう決めればいい?

A. 目に見える範囲を広く浅く理解しつつ、意図的にレイヤや適用範囲を変えたりする。手を出せる範囲は出せばいい。知的体力があるうちは絞らなくていいんじゃないかと思います。知的体力が監査領域を決める。大事なのは1本だけ鍛えるとか近くばかり鍛えるのが一番危ないということ。

 

Q. ペアプロ。コミットの間の決断をすることができるというのについて。役割を交代するタイミングで気にしている点。

A. とにかく喋ること。ドライバーもナビゲーターもとにかく喋る。喋ることは考えていることを再整理してアウトプットするということ。あとは相手を怯えさせないこと。

 

Q. (前質問につなげて)会話の引き出し方は?

A. オープンクエスチョンとクローズクエスチョンを相手の性格や理解から使い分ける。相手の緊張をほぐす。失敗してみせること。ボロボロの試行錯誤のプロセスを見せること。

 

Q. 最近流行ってるテクノロジーや新しいものを学ぶきっかけをどう決めているか?

A. 人を見ています。目利きをフォローする。この技術領域においてはこの人の情報収集力と整理力を尊敬している人をフォローすることによって一種のフィルタリングをすることができる。情報感度が高い人が何をwatchしているのかをwatchする。

 

Q. プロのプログラマってどんな人だと思いますか?

A. 自分が行うアウトプットとかコードに対して説明責任を果たせること。どういうことを考えてこういうことになっていますというのを説明できる。考えなしのコードを書かない。与えられた環境でベストを尽くす。特定の状況で何を活かせて何を活かせないかを判断できること。

スピードと質はトレードオフではない。与えられた状況で最大のスピードと最大の質でコードを書けるのがプロだ。