ダブルワークの初日を終えての感想（やるべきかやらざるべきか）

ダブルワークの初日を終えての感想（やるべきかやらざるべきか）

今日は前回の記事で書いたもう一つの現場の初日でした。
いやぁ〜想像してたのよりキツかったです。
プログラマという仕事柄、プロフェッショナルなところを求められるわけですが、脳の瞬発力が辛いです。

私は深く考えるタイプなので、こういうの得意な方が羨ましい。
で、私のようなタイプだと「どちらもMAXな力が出ない」ということがわかりました。
まぁ、慣れかもしれないけどね。

私に求められているポジション

どちらもバックエンドエンジニアとしての貢献を求められています。
で、どちらも要件定義レベルからの参画を求められています。

要件定義しながら実装を進めるという段階の現場A。
要件定義は固まっているのでそれで問題ないかの掘り下げの段階の現場B
なんだけど、現場Bは（初日だから）まずは現時点のコード読んで全体像の把握。

人のコード見るのって結構頭使うのよ。
という事で、本日は今までの現場はあまり手をつけることができず、新現場の概要を掴む事に注力してしまいました。
最初はね、2時間交代くらいで案件入れ替えて動こうと思ったのだけど、無理だった。
で、この時間まで仕事やって時間的な欠損を埋めていたのです。

ダブルワークは細かな現場だと辛いかも

今回の新しい現場ですが、夕会の報告が細かくて驚きました。
私の感覚だと、PMの役割は全体像のコントロールで詳細は個々のプログラマに任せ繋ぎ込むパーツに注視するイメージでした。
実際私がPMのような事をしていた現場ではそんな振る舞いしてたし、個別のコードの詳細なんて気にしなかったのですが、新現場のPMはすごく細かかったです。
「PMさん、そこまで聴いてコントロールできてるのかな」と思う程に。

こういう現場だとやったことを細かく報告することになるので、ダブルワーカーとしては時間の割り振り頭を悩ませそうです。
まぁね、面談時に「時間をどう使ってもいいけど、やってるように振る舞ってくれ」と言われたので「そういうことか」って思いましたけど。

ダブルワークは技術的な知見を深める

これ、たった1日の勤務で経験できました。
人のコードを見る量が増えるというのもそうですが、他の現場で選択しなかった実装を選択していたりと言った事があります。
今回でいえば「DynamoDBとBackendフレームワークとの繋ぎ込み」にLambdaを介すかという選択でした。

現場BではConfigに登録してDynamoDBを直接参照するという手段を取ってました。
ネットの情報ってLamdbaでゴニョるタイプが多いので現場Aで選択肢に上がったものの選ばなかった直Read型をここで体験できるとは。

こういう1つ1つの経験が蓄積されてプログラマのスキルになるわけですけど、ダブルワーカーは人の倍経験できます。
という事で、技術力を磨きたければ【ダブルワーク】は非常に有効な手段です。

まとめ

取り止めのない話になってしまいましたが、個人的な見解をまとめます。

ダブルワークをすることで、いろんな人の知識や考え方に触れる事ができます。
プログラマはいろんな現場に出入りしていても（職歴が複数あっても）差別されません。
その理由は「どれだけ経験を積んでいるか」が重要視されるからだと思います。

そう言った意味で、ダブルワークは自分自身にバフをかける手段の一つです。
やり続けるかは別として、一度は経験することをお勧めします。