新人エンジニア、配属されて間もない時は３か月くらいほんとにしんどいと思う。
実際私もしんどかった。未経験からってのもあったが、
大学から学んでいてもしんどいって話を聞いた。
言語やプログラミングはあんまり関係ない。
社会人として・・・みたいな話になるのでできる人との違いをまとめてみた
これができてれば『仕事』としてはOKだと思う。
エンジニアだからってこともないので、もしエンジニア嫌になっても見返そう。
忙しく字のごとく忙殺されそうなときは
これを思い出して読んでみてmm
１．反応は常に早く
わからないことは山ほどあると思う。
その時意識してほしいのは「早めに助けを求めること」だ。
相手は思ってる以上に、あなたができると思っている。
『言わなきゃ伝わんないんだ』って常に思って、早めに相談、質問とかしよう。
他にも、顧客からの連絡や、先輩上司からの連絡。
とにかく自分以外の人からの連絡には、早く反応しよう。
すぐに返答できない場合は「明日の午前中までに返信します」みたいに答えて、だいたいの期限を切った上で対応を後回しに。
よくないのは「自分の手が空くまで全く返信しない」とか「完全な回答ができあがるまで返信しない」という対応。
こうなると相手は自分の声が届いているのか、それともまったく届いていないのかわからなくなり、不安を感じてしまう。これは、今後の関係にも響いてくる
目安としては「遅くとも半日以内」という感覚。
Slackだと1,2時間くらいには返したいなぁ。。
勘違いしないで欲しいのは、あくまで「反応」するだけ。
（あなたのメッセージはたしかに受け取りましたよ！と返すだけ）
「すぐに対応を開始する」の意味ではないことに注意してね。
２．期限を確認する
問い合わせや作業依頼が来た場合は、）必ず対応期限を確認するように。
緊急を要する要件でないのなら、
TODOリストに入れたり、付箋に書いてまずは優先度高い作業を優先したりと、
しかるべきタイミングで対応しよう。
「問い合わせが来た！早く答えなきゃ！」とすぐに対応してしまうと、
そのぶん他のタスクがどんどん遅れるので、何をいつまでやればいいのかは意識しよう。
できたらでいいけどね。
３．困ったら早めに人に頼る
仕事にも簡単なタスクと難しいタスクがあります。
特に、プログラムを組むときは
「初めて使うライブラリなので使い方がわからん！」
「原因不明のエラーが出て全然解決できねえ！！」
みたいなことがときどき発生します。
そんなとき、20〜30分悩んでうまくいかなかった場合は、
自分のアホさ加減を素直に受け入れて、
トラブルを解決してくれそうな誰かに頼るようにしています。
なぜなら一人でずっと悩むより、
誰かに頼ってぱっと解決する方が圧倒的に効率が良いからです。
えっ？こんなこともわからないってバカにされるって？
わからないことを放置して勝手自己判断して実行したり、
悶々と悩んで何時間も進まない方がはっきり言って迷惑です。
だから安心して質問しましょうね
みんな同じ道通ってきましたし。
４．大きなタスクは小さなタスクに分解する
何時間も（あるいは何日も）かかるような大きなタスクは
事前に小さなタスクに分解します。
「小さなタスク」の目安は、だいたい30分から1時間ぐらい、
長くても2〜3時間で終わるぐらいのボリュームです。
大きなタスクがTODOリストに載っているとなかなかDONEになりませんが
、小さなタスクであれば小気味よくDONEにしていくことができます。
タスクを小さく分解して「進捗してるぞ、着実に前に進んでるぞ」という感覚を自分の中で味わえるようにしておくことも、仕事をする上では大事です。
５．完璧を目指さない
比較的大きめのタスクに取り組むときは、「それっぽい雑な成果物」が出来た時点でレビューを依頼し、フィードバックをもらうようにしています。
結論を言うと「最後まで完璧に作り込んでからレビューしてもらう」という方式は危険です。
なぜなら、自分の誤解や思い込みを含んだまま最後まで突っ走ると
手戻りが発生して余計に時間が掛かるからです。
そうならないように「そこそこ」の成果物を見せて、
方向性が間違っていないことをお互いに確認し合う方が効率的です。
初回レビューのタイミングは予め決める
また、タスクに着手する前から「ざっくりこれぐらい作って、いったんレビューしてもらう」という計画を立てておくようにします。
「ざっくり作った状態」というのはプログラムでいうと、たとえば「エラー処理や見た目の仕上げは未着手だが、正常系の操作であればいちおう動く」といった状態です。
つまり、「エラー処理や見た目の仕上げ」は
「初回レビューのあとに着手する」という計画を事前に立てておくことが大事です。
「拙速は巧遅に勝る」
これに関連する話として「拙速は巧遅に勝る」という格言があります。
仕事の出来がよくて遅いよりは、出来はわるくとも速いほうがよい。
Facebook創設者
マーク・ザッカーバーグもこういっております。
「Done is better than perfect 」
つまり
「完璧なプログラムを組む」
ではなく
「とりあえず動くもの」をとりあえず書いて形にする
それを繰り返すしかないということです。
小さなことも積み重ねれば
成長に繋がります。
３カ月くらいはエンジニアしんどいですが、
20代前半で見切りをつけるようなもったいないことはしないようにしましょうね。