思ったこと感じたことをつらつらと
コードの良し悪しについては昔書いたのでそちらを参照してください
経歴やスキルセットなど
- 2010 - 2011 クラウドサービスの開発/運用 (Java)
- 2011 - 2013 プラットフォームサービスの開発/運用 (Java)
- 2013 - 2015 モバイルサービスの開発/運用 (Java)
- 2015 - 2016 IoT サービスの開発/運用 ©
- 2017 - 2018 コンテナサービスの開発/運用 (Ruby)
- 2019 - 2020 クラウドサービスの開発/運用 (Python, Golang)
- 2020 - 2023 コンテナアプリケーションの開発 (Python)
- 2023 - Now スケジューラサービスの開発 (Python)
詳細はこちらを御覧ください
正直業界全体については語れないので完全に自分の世界での所感になります
マネジメントなどの経験はありません
すべてはアプリケーションでありソフトウェアな気がする
- Webアプリ、スマホアプリ、インフラ、ハードウェア、セキュリティ、機械学習などいろいろ経験したが最終的にはコードを書いていた気がする
- コードがあった上でそれぞれの分野に追加で必要な技術が出てくる
- 例えば Webアプリであればフレームワーク、ハードウェアであれば電気電子回路の知識、機械学習であれば三角関数や微分積分などの数学知識といった感じ
- そういった意味でどの業種もソフトウェアエンジニアであると思っている
コードから逃げてはいけない
- エンジニアである限りコードは一生ついてまわるものだと思っている
- なのでコードから逃げてしまうとエンジニアとして仕事ができないし成長もできなくなる
- コードから逃げると自分の首をしめることになるので結局つらくなるのは自分な気がする
- コードがわからない -> エンハンスやバグ修正ができない -> レガシーなコードになる -> 何もできなくなるの技術的負債ループに突入する
- コードが見れないツールやライブラリを使う業務は本当につらいと思う
- 責任分界点という意味では楽なのかれないがスピード感がでない
汎用的なスキルを身につけよう
- 究極に言えばオープンな技術だけ学べばいい
- 理由はどこに行っても通用するため
- クローズドな技術やツールは再利用できる機会が極端に少ないので別のところに行って使えないことが多い
- 具体的には自社ツールとかベンダー製品など
- その中でもオープンな技術を学べることはあるのですべてが無駄というわけでない
- API が付属していて REST のコールの仕方や SDK という技術、使い方について学べるかもしれないなど
- それでもオープンな技術を学ぶほうが最終的なレベルアップ度合いは大きいと思っている
- 汎用的なスキルとともにスキルの身につけ方、王道のサービスの構築手法やアプローチも身に着けたい (スクラム、ウォータフロー、DDDなど)
広く深くいろいろな技術を学ぶ
- 深く狭くだと限定的なエンジニアになってしまいそう
- いろいろなところで活躍したいなら広く深くが必要
- 常にリスキリングというか新しいことを学ぶ意識が大事
- 仕事で使っているスキルは勝手に広く深くなる
- そうじゃないスキル、流行りのスキルをどうキャッチアップするか
やるべきこととやらなくていいことを見極める
- 自分は仕事でもプライベートでも無駄なことが嫌いなので無駄は極力排除したいと思っている
- 例えばコーディングにおいては最低限のことだけやる
- 作らなくてもいいサービスや機能は作らない
- 作らなくてもいいという線引きが難しいが簡単に言えば無くてもサービスが継続できるならやらなくてもいいと思っている
- 作ったら作ったでそれを運用するコストが出てくる
- コーディングだけでなくツールの導入なども同じ、導入したらしただけそれを面倒みる必要がある
- 特にかくシンプルにやることを心がけたほうがいい
- ただ何もしないとしないでモダンな技術に触れる機会がなくなるのでそこのトレードオフもある
最短距離を走る
- 無駄を作らないための手法でもある
- ある機能やサービスを作るときにゴールは1, 2個だがそこまでいくアプローチは100も200もあると思っている
- そのいくつもあるアプローチから最適かつ最短距離を見つけられるかが重要
- ただそればっかりは技術とかではなく経験が非常にものを言うと思っている
- 開発の経験を重ねるとあるお題が与えられたときにパッと「あー、これはこうだからこれとこれを使えば簡単にできそうだな」「これはやりすぎだな」みたいなことがすぐに出てくるようになる気がする
- オーバーエンジニアリングしない
1から全部やり直せるくらいになる
- 自分の経験として前任者がいなくなったサービスをメンテナンスする業務が多くあった
- その中で既存のコードをメンテナンスするよりかは1から全部作り直したほうが良いケースが結構あった
- そのときに既存のコードを読み解き新たに作り直せると将来的も良いケースが多くあった
- よくわからないコードをメンテンナンスする、全然メンテンナンスされていない脆弱なコードをメンテナンスするくらいな作り直したほうが良いことがある
- おもいって新しく作り直すという方向に舵を切れるかどうかの判断も大事
レベルの平準化問題、属人化問題
- チーム全員を同じレベルにするのが難しい
- 開発を一人でやるとサービスが属人化する
- 開発後に運用でジョインするとかなり大変なので開発の段階からやったほうがいい
- スキルセットの違いによるスタートダッシュをどう埋めるか
- 教育するしかないがそれにかかるコストもゼロじゃない
- 勝手に学び勝手に成長してくれるという貴重な人材
仕事以外の自分の趣味をしっかり作る
- プログラミングが趣味でもいいとは思う
- ようするにリフレッシュできることを作ったほうがいいという話
- メリハリがあるほうが仕事もはかどるし学びの効率も上がると思っている
- ストレス発散
ChatGPT
- たまーに嘘をつくが便利
- 使いこなせば強力
- トラブルシューティングや Web にないコーディング方法が知りたいときにもしかしたらと思って使う
- 過度な期待はしない
- Google との併用
- 全部書いてもらいたいが技術的負債になってはいけない、自動生成されたコードはブラックボックスになりやすい
やったことは忘れないように記録する
- 自分もやっているがブログがおすすめ
- 動画だとコードの内容をコピペできないのでテキストがいい
- 広く深くを全部覚えてることはできないのでいつでもひっぱり出せる知識データベース的なのを作る
- 資格などの証明ではないが public に公開している自分の知識があればやったこと経験したことの証明になる
最後に
プログラミング楽しい
昔から図工とかものを作るのが好きだったから天職だったのかもしれない
0 件のコメント:
コメントを投稿