動いたところで満足して終わりにしない
はい。
書き上がったあとに何をするべきか
あなたにチケットが割り振られているとする。
駆け出しの貴方にとってはどれも初めて実装するような機能ばかり、あれこれ試行錯誤してようやく動くようになったッッ……！！とする。
そこがスタートラインになる。
なぜなら（よほど終わってる職場でもない限り）新人に実現できるかどうか不明瞭なタスクを割り当てたりしないからだ。つまり貴方が受け取るタスクは、少なくとも理論上は必ず完遂できるものなはずだ*1。
新人にタスクを振るときに先輩社員が考えていることのパターンはおおむね以下の通りになる
- null
- とりあえず簡単そうなタスクを振って実力をはかりたい
- ちょっと難しめの仕事をしてもらって成長して欲しい
- クッッソ忙しいので助けて欲しい
このうち4のパターンを引いたときは先輩が可哀想なので適当なところでさっさと切り上げて提出してあげよう。
2, 3のケースにおいては、タスクの完遂自体はそれほど重要じゃないことがわかるだろう。
では具体的にどうするべきかというと、以下を一通りさらってから完成として提出するべきだ
試行錯誤で膨れ上がったソースコードから不要なものを削る
ある程度の経験年数を踏んだ人であってもこれをやらない人が非常に多いが、ことプログラミングという点においてその成長は遅くなる。
なぜならいくら経験を積んでも、過去にやってきた作業について「最小の再現手順」を置き去りにしてきているからだ。余談だがコードをある程度読めばその人がこの習慣を持っているかどうかはすぐにわかる。ノイズが多いからだ。
自分が完成させたコードよりもより良い実現方法はなかったのか調べる
「頑張って何行も書いたコードだったけど、標準ライブラリを呼び出せば一行で終わりだった」
「上級者のエレガントな解法が10倍簡潔でパフォーマンスもよかった」
誰しもが一度は経験したことがあるとおもう。他人からも読みやすいように調整する
リーダブルコードの教えに従ったり、適切なコメントを入れたりなどだ。
他人からも読みやすいコードを書く、というのはあやふやな表現だと感じるかもしれない。実際、”読みやすさ”というものは文化や環境に左右されるものなのでここはかなり経験が要求される上級者向けの項目だ。
とはいえ何も挑戦しなければ一生駆け出したままなのでどんどん挑戦しよう。
チケットの期限が許す限りは以上のブラシュアップ手順を何サイクルかしてから提出するようにしよう。
これを繰り返していると基礎体力がつくし、次に似たようなものを実装するとき*2は前回の復習の内容が直接活きる。
もしいきなり超完成度でタスクが仕上がってしまって改善のしようがない……という場合は駆け出しにしてすでに極みに達しているか、割り振られたタスクのレベルがあまりに低すぎる可能性があるのでいずれにせよ先輩に相談しよう（言葉は選ぼう）。
最後に
再現性の高さというのはあらゆる局面で大事になる概念なので覚えておこう。
エンジニアの方であれば「再現性」ときいてまずバグの報告やなんかが思い浮かぶとおもうが、技能の上達という点でも非常に大事となる。
例えばサッカーで「すげえドリブルでめっちゃ抜いていい感じにコーナーからクロスしてドーン！！」は複雑だし、状況に左右される要素が多いので再現度が低い。なのでパスやシュートなど、再現性の高い部分の練習から精度を高めてセットプレー的なメニューに入り、練習試合を通じて血肉とするわけだ。
今回あげた3つの工程は基礎練習に当たる。
Railsでいい感じのサービスをつくってポートフォリオにアッピール！！GitHub活！！フリーランスで年収1000万円！！！！ みたいな華やかさはないが、毎回続けていれば間違いなく成長に繋がる。
ちなみに今回のタイトルは駆け出しエンジニアと繋がりたいとかいう詐欺師とbotと少しのカモが闊歩する気色悪いタグにちなんでます。
駆け出しの人が駆け出しアピールをすると大量の有象無象が沸いてきて、悪意や親切心から色々なクソ情報を吹き込んでくるのです。怖いですね。
