Open44

「ソフトウェアエンジニアとしての姿勢と心構え」を実践する

mskmsk

概要

以前と比較して、勉強に確保できる時間が減った。
限られた時間で効率的に取り組むための、t_wada さんの資料ソフトウェアエンジニアとしての姿勢と心構えを実践する。

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022

Agenda の項目を細分化して、自分なりの解釈を実践し、記録を残す。

mskmsk

Agenda より

資料の Agenda は以下になっている。それぞれがさらに細分化されているので、深堀する。

  • 学び方を学ぶ
  • 現役プログラマでいるために

勝手に図解

mskmsk

「学び方を学ぶ」> 1.「月に 1 冊のペースで技術書を読む」を実践

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022?slide=14

mskmsk

内容

たとえば、時系列に並べる
書籍の時代からテックブログの時代へ

mskmsk

解釈

多分、表題の通り「毎月 1 冊の技術書を読む」ということ。

あとは以下を決める

  • どの技術書(テックブログ?)を読むのか
  • 「読んだ」とは何なのか

どの技術書(テックブログ?)を読むのか

すぐに役立つもの、なんとなく興味があるもの、英語・日本語、概念、コードの HowTo なのか

「読んだ」とは何なのか

理解できたこと、次の行動に移せること、時系列を抑えられていること、何に影響を与えたのかはっきりしていること

mskmsk

実践

自分の興味関心のある技術書を読んで自分のブログに感想を投稿する。
2024年4月現在だと、DevOps・SRE、Kotlin、英語関連の本。
読んだ目的と読んだことによる変化を残す。

https://msksgm.hatenablog.com/archive

mskmsk

「学び方を学ぶ」> 2.「手を動かして学ぶ」を実践

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022?slide=19

mskmsk

解釈

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

「やる -> できる」が「やる -> できない」が発生するかもしれない。
理由は、実力不足であり自分の興味関心外だったとか。
だから「できる」の定義も必要そう。

手を動かす

手を動かして学ぶ方法

  • 書籍やサンプルコードを写す
  • アプリを自作する

写経

写経対象について

  • OSS
  • 書籍
  • ネットのサンプルコード

アプリの自作

作るものは、以下のどちらか。

  • 後述の身の回りのものをプログラミングする
  • 毎年少なくとも 1 つの言語を取得する
mskmsk

実践

個人 OKR で、「手を動かして学ぶ」を組み込む。
それが個人開発だったり、OSS の写経になることは問わない。

mskmsk
mskmsk

解釈

きのこの、以下の内容

「習得する」について

習得の定義の概要

  • 基本的なイディオムやフレームワークを知っていること?
    • 結局、都度調べることになるのでこれを定義にすると難しいかも
  • RealWorld を実装する
    • 全てのプログラミング言語が Web アプリケーション向きではないので、必ずしもそうとはいえない
    • BE のテスト実装が若干しんどい。BE に限定するなら、e2e テストを自動化したい

「文化を学ぶ」について

文化とは?

生まれた背景 -> 公式サイト、Wikipedia
言語が解決したいもの -> シンタックスの比較?

mskmsk

実践

個人 OKR に言語の習得も含める。
期間は最小で 3 ヶ月で、最長で 6 ヶ月をめどにしたい。

言語の選定方法は、要検討。
Web アプリケーションベースで考えるのか、CLI ツールとして考えるのかで変わりそう。
また、可能であれば興味関心から延長したものしたいけど、うまくいくとも思えない。
例えば、最近の興味、関数型のエラーハンドリングから Scala、Rust が候補に入る。
だけど、Web アプリケーションベースによっている気がする。

mskmsk

「学び方を学ぶ」> 4. 「身の回りをプログラミング対象にする」を実践

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022?slide=36

mskmsk

内容

「プログラマ向けの本の監修者はどあるべきか」で実践していた。

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

解釈

自己分析ベースで考える。これらをどうあるべきか考えないといけない。

技術的な側面

  • 企業の Web エンジニア
    • プロダクト開発エンジニア
    • SRE
  • 毎日技術的な勉強をしている
    • ブログまたは zenn に公開
    • Kotlin(Spring)をもっと普及させたい
    • DevOps・SRE に興味がある

技術的でない側面

  • 成人男性
    • 衣食住
    • お金
  • 趣味
    • 勉強
    • コーヒー
    • サウナ
    • 美術
mskmsk

実践

とりあえずはスモールステップで考えたいが具体的な案が思いつかない。
多分、複雑に考えすぎ何だと思う。
「個人アジャイル」で検索したら、以下の記事がでてきた。

https://logmi.jp/tech/articles/329327

今回のことを雑に個人に当てはめると、

中長期的な目標 -> エンジニアとして学び続けられていること
短期的な目標 -> モチベーションを維持しながら開発を続けるために、身の回りのことをプログラミング対象にしたい
超短期的な目標 -> 簡単なスクリプトでもいいから、自分のことをエンジニアリングする目標を立てて自己フィードバックを獲得する

になる。

だから、技術的な側面と技術的な側面をどちらを選んでも、中長期的な目標を達成するための短期的な目標であれば良いとしよう。

mskmsk

「学び方を学ぶ」> 5. 「アウトプットを行う」を実践

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022?slide=44

mskmsk

内容

  • 正のフィードバックループ
  • 量は質に転化する

アウトプットのチャネル

  • Twitter
  • blog、Qiita 等
  • 雑誌記事(Web、紙媒体、電子媒体)
  • 書籍(共著、翻訳、監訳、単著)
  • 公演(社内勉強会、社外LT、社外公演)
  • ライブコーディング
  • GitHub
mskmsk

解釈

  • アウトプットをこなす
  • さまざまな箇所でアウトプットする
mskmsk

実践

1 年のなかでアウトプットのチャネルを一つに固執するのではなく、バランスよく配分したい。

  • Twitter(X) -> X でのツイートをアウトプットと呼ぶのは個人的に避けたい。。。
  • blog、Qiita 等 -> zenn、hatena
  • 雑誌記事 -> どうするんだ?依頼?
  • 書籍 -> これも難しい。。。
  • 公演(社内勉強会、社内LT、社外公演)-> 社内はハードルが低いので、短いスパンで実践したい。社外は上期下期で平均 1 程度?
  • ライブコーディング -> これも難しい
  • GitHub -> 「身の回りのものをプログラミングする」「毎年1つの言語を習得する」を実践?
mskmsk

「現役プログラマでいるために」> 1.「毎日コードを書く」を実践

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022?slide=60

mskmsk

内容

John Resig の 4 つのルール

  1. 毎日コードを書くこと。ブログ、ドキュメント、その他はコードを書いたらやってよい
  2. 意味のあるコードを書くこと。インデントとやフォーマットの修正、可能ならばリファクタリングもコード書きにはカウントしない
  3. 深夜 24 時前には終わらせること
  4. 書いたコードを github で全て OSS にすること
mskmsk

解釈

意味のあるコードが難しいと思った。
zenn、hatena を Markdown で管理しているので、それのせい(おかげ?)で github に芝を生やせている。

「手を動かして学ぶ」「毎年1つの言語を習得する」「身の回りのプログラミングする」の過程で出したい

mskmsk

実践

「手を動かして学ぶ」「毎年1つの言語を習得する」「身の回りのプログラミングする」をやろう

mskmsk

「現役プログラマでいるために」> 2.「年下から学ぶ」を実践

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022?slide=74

mskmsk

内容

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

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

解釈

若者の定義について

シンプルに年下なのか、技術を学んだコンテキストの違いなのかといった解釈がありそう。
具体例:ChatGPT、GitHub Copilot が生まれた後と生まれる前のプログラミング初学者の違い

若者と同じ土俵について

ポジションが違えば、土俵も変わるので、一概に同じ土俵に立てるものなんだろうか。
競技的な側面が強いもの(競プロ、ISUCON、Kaggle など)はフィールドを揃えやすそうだけど、必ずしもそうなのか。

mskmsk

実践

仮想の若者を作ると良いかも。
技術記事、GitHub、トレンドから考えてみたり。

mskmsk
mskmsk

「現役プログラマでいるために」> 4.「人のつくる渦を見る」を実践

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022?slide=88

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

mskmsk

内容

しかし、今の業界は、「エコシステム」の時代だ。熱帯雨林のように、食いあいつつ共生しあうさまざなタイプのプレイヤーが、自分の為だけの個別の意思決定をして、その相互作用で技術が発展していく。
「ロードマップ」が指し示す未来の方向と違う方向に進むことは致命的な間違いだが、「エコシステム」はむしろ中心部がレッドオーシャンで、周辺部に生き残りが容易なブルーオーシャンがある。「エコシステム」の中で王道を進むには、並みはずれた他の者にはない強みを持っている必要がある。
普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ。

mskmsk

解釈

自分にとっての、ロードマップとエコシステムとは。
今の自分のが業務・個人問わずやっていること

  • SRE・DevOps
  • Kotlin
mskmsk

「現役プログラマでいるために」> 5.「大事なことに集中する」を実践

https://speakerdeck.com/recruitengineers/software-engineers-survival-guide-2022?slide=99

mskmsk

解釈

情報が足りなくてわからなかった。。