junior engneerがインターン先Rでそこそこちゃんと仕事をして思ったことまとめ

ライブラリの選定

何かプラグインなり、ライブラリを使いたい時は、なぜそれを使いたいのか、なぜそれが良いと思うか、どう使いたいかを伝える。

ライブラリ導入時のチェック項目

[ ] issueの数
[ ] 星の数
[ ] それに関連する技術のバージョンを調べる
[ ] 何年前から使われているか調べる（枯れているか）

仕事の順序

(自分が手がけているプロジェクトと同様の環境の遊び場を使っていじったりする)

1.ゴールを理解する、解決したいことを明確にする（それについてわからないこと、知りたいことを明確にする、それは調べる方法（ググるのか、githubでコードを読むのか）も同様） ex)　一部のリソースへアクセスするポリシーの作りかた、またそのコード

2.その解決方法を調べて、上長にこの方向で解決しようと思うのだがどうか？（自分なりの仮説、メリットデメリットを具体的かつ簡潔に伝える）という形で質問する

3.PRをwipで出して、実装方針を整理し、正しい方向性か上長に聞く。そのコードについて深く考える。その冗長だったら何て言うか考える。

4.PRのreviewをお願いする。PRはreviewerが疑問に思う可能性がある処についてなぜそうしたのか、ちゃんと説明す。reviewerの負担を減らすことを考える、他のメンバーのことも考える。

一言

「仕事とはただqiitaにまとめてあるような実装をして、コードを書いて動かすようにするだけではない。そのコードに責任感を持ち、問題解決を行うのが仕事である。」と思いました。

なんか自分がやってきたことってわりとrailsのコードを書いて何かを動かすようにするという感じで、しかもゴリゴリのスタートアップだったのでとりあえず動くようにして当然のごとくテストなんて書かないしという感じだったので、仕事といえばただ動かすようにすればいいという感じでした。だから、Rに入って技術選定からドキュメントの作成、社内でのコミュニケーションなどあーエンジニアってコード書くだけじゃなくて、問題解決が仕事なんだと思いました。なんか自分で作る時はデバッグして動いたー！！楽しい！！って感じだけど、仕事はそうじゃないなと。ググって一番上に出て来たやつを何も考えずに採用している場合ではないなとおもいました。

あと仕事って最終的なゴールはこのフローを上長の存在なしでできるようにすることだと思う。そうすると自然と上長に何か聞くことが少なくなって、あいつは「仕事ができる」ということになるのではないか。

また明日から頑張っていきたい。