tawara's blog

雑記。個人の見解です。

成長が止まっている?

エンジニアとして働きはじめて1年と7ヶ月が経った。最近あんまり成長してないなーと思うことが増えた。同じくらいにこの業界に入った友人や知人がいるけれど、彼らに比べたらそこまで成長できていないと思っている自分がいる。そんなふうに感じているだけだと、気持ちが後ろ向きになってしまうので、いったん言語化をしてみる。どのようなときにそう感じるか、何が課題なのか、課題へのネクストアクションは何なのか、を言葉にしてみる。

  • テーブル設計をしているときに、
    • イケてる設計の判断基準がわからず設計に自信が持てずもやもやしてしまう。なので、
      • これは早い段階でチームのエンジニアに相談するようにしている。で、彼らが何を根拠にしているかを聞いて勉強している。
      • データモデリングというのを知ったので、関連書籍を読んでみるとかもよいかも。
      • 個人開発でテーブル設計の経験をしまくってみる。ただ長く開発してみることが求められるかも。。。
  • SQLを作るときに、
    • SQLを意識してActiveRecordを操作できない。joinやincludeの違いを説明できない。それらの違いがわからないので、どれを使っていいかわからず、似たようなコードを真似るにとどまる。なので、
      • SQLの初歩的な知識から学習する(書籍、動画など)。
      • SQL Zooとかいう学習サイトをやる。
  • 複雑な配列やハッシュを操作するときに、
    • ループが二段階くらいになったり、配列のなかにhashやhashのなかに配列があると頭で処理できずパンクする。進捗がなくてイライラしてしまう。なので
      • AtCorderの過去問を問いたりする(再開する)。
      • Rubyの基礎知識の再学習する(積読の消化)。
      • 部門内で質問する。
  • プロダクトのソースリーディングしているときに、
    • どこを理解すればコアを理解したことになるのかの判断が遅く、効率が悪い。自分が効率悪いことに対してイライラする(これは別の課題かな)。なので、
      • ソースリーディングのゴールをその都度定める。
      • 知見ある同僚に解説してもらう
  • バックログリファインメントで実装可能か議論のとき、
    • 可否の判断ができない。この会議で何も役に立ってないなと思ってしまう。なので
      • まずはプロダクトを理解する、なのかな。これむずいな、、、
  • プランニングポーカーでチケットの見積のときに、
    • 見積の判断基準にいまいち自信が持てない。なので、
      • 判断基準が正確な人に話を訊いてみる。ファイル数、処理の複雑さ、コアロジックに修正がいるか否か、とかなのかな。うーん。

で、何からやるべきなのかを考えたい。仕事の成果につながるものから着手すべきか。そう考えるとプロダクトコードの理解がいちばんな気がする。ただどこをどうソースリーディングすればいいのか、の精度があいまいなのでそこを同僚とかに聞いていい感じにしよう。土日に教えてもらうわけにはいかないので、業務内でヘルプを出すようにしよう。

プライベートの時間で学習する優先順位はどうだろう。Rubyの配列やハッシュ・SQLの学習や他にもGitの学習とかもしたい。とりあえずいちばん使うRubyを再学習するとしよう。

もやもやしていた原因を、業務とプライベートで分割できたのでとりあえずよしとする。

(了)