こんにちは
プログラマー / マネージャー のAです。
今日、新入社員をチームに迎えました。
エンジニアリングに愛情があって、
上質な情報に触れていて、色々と目の付け所が良く、期待しています。
ただし、
初めての職業プログラミングにつき、
イメージ と 現実とのギャップに苦しむと思います。
その解決案として、
昔(6,7年前)はこう考えていたけど、今はこう考えるようになった、
的な遷移を書いてみます。
同じことで悩んで、苦しんで、というのは無駄なので
少しでもショートカットになればいいな という感じです。
時間と品質は両立できない →両立出来るし、両立すべき。
時間をかけずに作ればエラーが出る。
エラー出ないように作れば時間がかかる。
どっちも満たすのは無理。
とよく思ってました。
ただ、
残念ですが、
前提として、
どちらかを満たしたからOK という状況はまずないです。
諦めてください。
ただ、
幸い、
どちらも満たすためのやり方は 先人が生み出しています。
それに倣うため、ルール・指示を守り、先人が作った道をまずなぞりましょう。
上手くいかない時こそ、既にある道を歩きましょう。
少し話がズレそうなんですが
そもそも「両立」の定義が間違ってる場合がよくあります。
「時間と質の両立なんか無理」
って思ってしまったときは、そもそも「両立」ってなんだ?って考えてみてください。
オリジナリティは大事
→ 大事。でも、時間と品質の保証が一番大事。
入社してすぐのこと。
今でも覚えてるんですが
メール文面の最後の署名を、上司のを参考にして自分で作って、
怒られたのを覚えています。
今思うと不思議なんですが
「何事もマネしちゃいけない」と思っていて、
悪意なくやった感じです。
一応ですが
マネしてはいけない ルールはありません。
時間 と 品質 が保証されればOKです。
署名の件で言えば、
マネをした方がいい理由は明確で
時間 => コピペ一発で終わるので時間はかからないから。
品質 => 長年使われているので、品質も保証されてるから。
になります。
ただ、オリジナリティ自体の否定はしません。
プログラムを書いていると、
覚悟を持って、オリジナリティを出さないといけないタイミングが来ます。
守破離の 「破」 とか 「離」 とかのタイミングですね。
既存のモノに倣い続けていると
バグが止まらなくなったり、
スピードが落ちてきたりします。
そういうときは、オリジナリティ と 覚悟 をもって踏み出してください。
くれぐれも
マネする理由を
「他の人がやってるから、失敗した時に他の人のせいに出来る」
にならないように注意を。
今回はココで終わりますが
次回も同じ書き方で書いてみようと思います。