成長が止まっている?
エンジニアとして働きはじめて1年と7ヶ月が経った。最近あんまり成長してないなーと思うことが増えた。同じくらいにこの業界に入った友人や知人がいるけれど、彼らに比べたらそこまで成長できていないと思っている自分がいる。そんなふうに感じているだけだと、気持ちが後ろ向きになってしまうので、いったん言語化をしてみる。どのようなときにそう感じるか、何が課題なのか、課題へのネクストアクションは何なのか、を言葉にしてみる。
- テーブル設計をしているときに、
- イケてる設計の判断基準がわからず設計に自信が持てずもやもやしてしまう。なので、
- これは早い段階でチームのエンジニアに相談するようにしている。で、彼らが何を根拠にしているかを聞いて勉強している。
- データモデリングというのを知ったので、関連書籍を読んでみるとかもよいかも。
- 個人開発でテーブル設計の経験をしまくってみる。ただ長く開発してみることが求められるかも。。。
- イケてる設計の判断基準がわからず設計に自信が持てずもやもやしてしまう。なので、
- SQLを作るときに、
- SQLを意識してActiveRecordを操作できない。joinやincludeの違いを説明できない。それらの違いがわからないので、どれを使っていいかわからず、似たようなコードを真似るにとどまる。なので、
- 複雑な配列やハッシュを操作するときに、
- プロダクトのソースリーディングしているときに、
- どこを理解すればコアを理解したことになるのかの判断が遅く、効率が悪い。自分が効率悪いことに対してイライラする(これは別の課題かな)。なので、
- ソースリーディングのゴールをその都度定める。
- 知見ある同僚に解説してもらう
- どこを理解すればコアを理解したことになるのかの判断が遅く、効率が悪い。自分が効率悪いことに対してイライラする(これは別の課題かな)。なので、
- バックログリファインメントで実装可能か議論のとき、
- 可否の判断ができない。この会議で何も役に立ってないなと思ってしまう。なので
- まずはプロダクトを理解する、なのかな。これむずいな、、、
- 可否の判断ができない。この会議で何も役に立ってないなと思ってしまう。なので
- プランニングポーカーでチケットの見積のときに、
- 見積の判断基準にいまいち自信が持てない。なので、
- 判断基準が正確な人に話を訊いてみる。ファイル数、処理の複雑さ、コアロジックに修正がいるか否か、とかなのかな。うーん。
- 見積の判断基準にいまいち自信が持てない。なので、
で、何からやるべきなのかを考えたい。仕事の成果につながるものから着手すべきか。そう考えるとプロダクトコードの理解がいちばんな気がする。ただどこをどうソースリーディングすればいいのか、の精度があいまいなのでそこを同僚とかに聞いていい感じにしよう。土日に教えてもらうわけにはいかないので、業務内でヘルプを出すようにしよう。
プライベートの時間で学習する優先順位はどうだろう。Rubyの配列やハッシュ・SQLの学習や他にもGitの学習とかもしたい。とりあえずいちばん使うRubyを再学習するとしよう。
もやもやしていた原因を、業務とプライベートで分割できたのでとりあえずよしとする。
(了)