エンジニアってやるべきことが多いなぁと思います。
粒度を雑に書いていくと
- 要件・要求の把握
- ドメイン理解
- 短・中・長期を見据えた設計
- 実装（固有技術の習得）
- フロントエンドもバックエンドもDBもインフラも…
- チームへの共有・ドキュメンテーション
- ステークホルダーコミュニケーション
- 自動テスト・CI/CDなどの基盤整備
- オブザーバビリティ
- セキュリティ
- チーム開発
- コードを書かない技術
などなどなど。１つのスキルを深堀りするだけでもかなりの時間を要し、チームやプロダクトによっては経験できないものもあったり、そもそも得意不得意があったりします。
エンジニアとして練度が上がってくるともちろんこういったことが身についてきて良い感じに課題解決できるようになるわけですが、とはいえ認知負荷の問題はあります。例えば実装しているときには例外パターンを考慮できていなかったり命名が適当になっていたり、コードを書かなくても良い解決方法を模索せずについついコードを書いてしまったり。
これ自体はしょうがないことなので、大事なのはチームとしてのレジリエンスを持っていることなのかなぁと思っていたりします。例えばレビュープロセスやデイリーMTGで指摘し合ったり、社内勉強会で共通認識を作ることで、こういった「うっかり」を減らせるし、チームであれば個人の認知負荷の限界を簡単に越えれます。得意不得意をチームで補うという感じ。シニアエンジニアでも抜け漏れはあるものなので、気にせず指摘し合えると良いのかなぁと思っています。
それはそれとして個人としてもこういった抜け漏れは減らしたいですよね。これは認知負荷を減らすのが鍵なのかなと思っています。
たとえば「実装」というタスクがあった場合、この中でも
- 正常系を書く
- 正常系のテストコードを書く
- 例外パターンを書く
- 例外パターンのテストコードを書く
- PRを作る
- セルフレビューしてみる
- レビュー依頼する
といった感じでやることを分割すると認知負荷を減らせます。セルフレビューも効果的で、IDEでコードを書く脳の使い方を、WebUIなどでコードを読む脳の使い方は結構違って、同じ人が同じコードを読む場合でも違う視点を手に入れることができます。また、１日寝かせることで固定観念を取り除くことができて「そもそもこうじゃなかったっけ…？」「実装しなくても解決できなかったっけ…？」といった視点になれるのでオススメです。