私は社会人になってからプログラムをはじめて、4年ほどになります。その経験から、新人だった頃の自分に伝えるなら、こんなことがあるというのがいくつか思いつき、折角なのでまとめることにしました。
やりたいことがなくても焦らなくていい
よく言われていますが、やるべきこと、やりたいこと、できることの3つが重なるものが取り組むのがよいです。まっとうな会社であれば、やるべきことをある程度提示してくれるはずですし、新人にはそうするのがセオリーです。その中からやりたいと思えることや、とりあえずやってもいいと思えるものをこなしていきましょう。そうしていけば、自分がどういう技術を好むのか、どういう仕事の進め方が良いのかが見えてきて、やりたいことがでてきます。
社会人になってからはじめたのであれば、やりたいことが曖昧なのはしょうがないことです。周りに流されて無理に見つけようとしなくても、仕事をこなす中で探していけばいいことです。
無理矢理、こちらのやりたいことを引き出せようとする時は、ちょっと疑った方がいいかもしれません。会社が迷走中かノープランなのかもしれません。
エンジニア文化に無理に染まらなくてもいい
気にいったら別のよいですが、そうでないなら無理にあわせようとしなくてもよいです。誰もが、ChatOpsしたり、毎週勉強会いったり、twitterしたり、エンジニア界隈のスラング使ったり、アニメやラノベを嗜んだり、自宅にサーバラックいれたり、ブログ書いたり、しなきゃいけないわけではないです。
自分が必要だなとか、良いなと思ったものを取り入れればいいです。
「お金のためにプログラム書いている」というスタンスでもいい
続けていくうちに、趣味としても時間をかけても良いと思えるようになったなら、どんどんやって良いと思います。
ただ、そうでないなら、自分の他のプライベートとの時間配分を考えて取り組んだ方がいいです。職業がら、勉強する時間をとらなければいけないですが、仕事にある程度直結するものを優先した方が、効率うんぬんよりも、精神衛生的に良いです。「食い扶持を稼ぐためにやっているのだから、極力仕事に関連するのだけやる」と割り切った方が、自分の中の一貫性を保ちやすいからです。
一番まずいのが、趣味でやっていることがやりたいことで、仕事のはやりたくないことという方向に進みすぎると、やりたくないことだから、仕事では適当にやっていいと、手を抜く言い訳を自分に与えてしまうことです。そうなるくらいなら、お金のためと割り切った方がいいでしょう。
問題解決こそが仕事
作業時間を短くする、コストをさげるなど、なんらかの問題を解決することこそが、仕事です。決して、流行のソフトウェアを導入することや、流行のプログラミング言語を使ったり、新しい技術情報を収集するだけのことではありません。
自分が抱えている問題の解決につながらなければ、もってる知識もやっていることも役立たず、と、時に厳しく見ることも大事です。
積極的に作業仮説をたてる
環境構築にしろ、プログラミングにしろ、デバッグにしろ、何かつまることがおおいです。そういうとき、正解を一発でだそうと立ち止まるよりも、具体的な作業ができるような仮説をたてることです。（これは学生時代に研究室の先生に教わったことでもあります。）
例えば、サーバにアクセスしようとしてできなかったときに、「ネットワークに問題がありそう」と仮説をたてます。
そうすると、「アクセスするサーバのファイアウォールではじかれているのか」とより具体的な仮説をたてます。これを検証するには、iptablesの設定値をドキュメントから取得するなり、接続しようとしているポートにアクセスできるかのコマンドを実行したりすることになります。
大雑把には下記のようなフローになります。
- 方針決めのための仮説をたてる
- 検証可能な、より具体的な仮説をたてる
- 仮説を検証する
- はずれなら、とりあえず2にもどる
- 2,3,4をなんどか繰り返して、方針が違うと分かったら1に戻る
この過程を踏むことで、たとえ仮説が間違っていたとしても、それが今回の場合はどうして違うかの知見が得られて、あっていたときはその理由を明確にできます。
問題の切り分けをする
上述の適用パターンですが、何かエラーがでた時は、必ず問題の切り分けをできる範囲でしましょう。そうすれば、他の人に聴くときも、的確な質問ができるようになります。
サーバ側かクライアント側の問題かどうかがわからないときは、どちらかが問題（例えばサーバ側）と仮説をたてて、それを検証します。検証した結果、サーバ側には問題なさそうと分かれば、クライアント側の方に意識を集中できます。
自分の問題を解決するためのアンテナをはる
コピペコードばかりしてしまう、複数台のサーバに、手動で同じ設定してしまう、テストに時間がかかりすぎる、テストの時間がとれない、など、自分の仕事の問題点をなんとなく意識にもっているとよいです。
欲をいえば、こうすれば解決できるのではというのもなんとなくもっていると、twitterやqiitaで流れてくる情報から、その問題を解決するものを拾えたりします。それにつながる本を見つけたり、ぐぐったときに必要なものをピックアップできるようになります。
ノウハウをさらしてもあなたの価値はさがらない、むしろあがる場合が多い
特許とかそういうものでない限りは、自分のノウハウをさらしていった方がよいです。そのことによって、自分が代替可能な歯車になるような気がしますが、そのことで自分の価値がすぐに下がることは滅多にないです。自分がやってきたことを他の人ができるようにすることで、可用性があがり、自分自身は他のことをする時間がとれるようになり、そのことであらたな価値を自身に追加できます。
他の人に作業を割り振れる能力があることを示すことになり、そのことでチームに貢献できます。
コードは機械への命令だけでなく、人に読んでもらうもの
昔は機械にどう命令するかという意味合いが強かったかもしれませんが、今となっては人間にとって読みやすいかどうかの方が重要だと思います。
他の人が読んで意味がわかるように書くのをこころがけましょう。明日の自分も、他人だとおもった方がいいです。すくなくとも、一週間もたったら、細かいことやどうしてそう書いたのかなどを結構抜け落ちます。そのためには、DDDやオブジェクト指向などの設計寄りのスキルが重要ですし、ドキュメンテーションコメントなどで補うこともできます。アルゴリズムや言語の使い方ばかりでなく、上のレイヤーのスキルを身につけた方が、効果的に可読性をあげられます。
よく寝て、よく運動する
寝不足と運動不足が重なると、人生詰みそうです。そこまで体調を崩したことはないですが、寝ないと回復しない、寝てばかりだと体が弱るというのが、30過ぎてから感じるようになってきました... 睡眠時間と運動の時間はちゃんととりましょう。体こそが最大の資本で、投資すべきものです。