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

Agenda より

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

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

勝手に図解

「学び方を学ぶ」

• 月に１冊のペースで技術書を読む
• 手を動かして学ぶ
• 毎年少なくとも言語を１つ学習する
• 身の回りをプログラミング対象にする
• アウトプットを行う

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

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

• 毎日コードを書く
• 年下から学ぶ
• 過去から未来を見る
• 人のつくる渦を見る
• 大事なことに集中する

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

内容

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

解釈

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

あとは以下を決める

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

どの技術書（テックブログ？）を読むのか

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

「読んだ」とは何なのか

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

実践

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

https://msksgm.hatenablog.com/archive

内容

「やる -> できる -> 好きになる」と「写経」についても触れられている。

https://twitter.com/t_wada/status/9000231741

解釈

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

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

手を動かす

手を動かして学ぶ方法

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

写経

写経対象について

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

アプリの自作

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

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

実践

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

解釈

きのこの、以下の内容

• プログラミング言語は複数習得すべき
• 言語だけでなく文化も学ぶ

「習得する」について

習得の定義の概要

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

「文化を学ぶ」について

文化とは？

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

実践

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

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

4月25日(木)

久しぶりに「達人プログラマー」を読んだ。
習慣的な箇所は目標に落とし込みたい。

https://msksgm.hatenablog.com/entry/2024/04/23/072900

内容

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

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

解釈

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

技術的な側面

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

技術的でない側面

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

実践

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

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

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

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

になる。

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

内容

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

アウトプットのチャネル

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

解釈

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

実践

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

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

内容

John Resig の 4 つのルール

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

解釈

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

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

実践

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

内容

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

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

解釈

若者の定義について

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

若者と同じ土俵について

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

実践

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

内容

技術は振り子ではなく螺旋の話。

実践

スライドを読んだことあったけど、ポッドキャストを聞いたことがなかったので聞く。

https://fukabori.fm/episode/28

https://fukabori.fm/episode/29

可能であれば、ほかの t_wada さんの fukabori.fm も聞いてみる。

内容

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

解釈

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

• SRE・DevOps
• Kotlin

実践

まずは、ロードマップとエコシステムを知らなければならない。
それは興味関心限らず言えそう。

ロードマップ

SRE

SRE エンタープライズロードマップ

https://static.googleusercontent.com/media/sre.google/ja//static/pdf/jp-enterprise-roadmap-to-sre.pdf

Kotlin

ロードマップじゃないけど、学習ガイドが公開されていた。

https://twitter.com/jetbrainsjp/status/1778364594060423240

内容

https://kanki-pub.co.jp/pub/book/9784761270438/

解釈

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

実践

エッセンシャル思考を読む

4月29日(月)

読んで感想文を書いた。
大事なことに集中するためには本書に書かれた内容を実践すれば良さそう。
1 つずつ項目をまとめて、達成度をだせると良いのかも。

https://msksgm.hatenablog.com/entry/2024/04/29/144443