去年一年の仕事を振り返っていて、いまいちコードを書いていないことに気づいてしまった。
プログラマの下っ端がコードを書かずに何をしているかというと、 バグのたらい回し、バグレポートの解析、コードレビュー、メールとか報告とかの自然言語書き、バグのたらい回しとか。 下っ端には下っ端の雑用があり、特に性能問題の分析は無限に時間を溶かしがち。去年はだいぶ溶かしてしまった。
その反省からもうちょっとコードを書こうと、去年のおわりくらいから午前中は雑用をすべてすっぽかしコードを書くことにしてみた。 いわゆる Write Code Every Day (WCED)。
やってみると腰が重くて放置していた積み残しの仕事たちがあれよあれよと片付き、コードも書けて満足度も高く、 なぜこれをやっていなかったのか（答: 色々な圧力があったから）不思議なくらい捗った。のだけれど、ここ一週間くらい行き詰まってきた。 というのも、即座にコードの書ける仕事が手元からなくなってしまった。
１つ目のパターンは、誰かを待つ必要がある仕事。わかりやすいのだとコードレビューとか。 あとは人のコードベースに踏み込んでなんかやるために方針を相談するとか。 話がつくまでそのあとの作業ができない。 まあこれは自分にとって付き合いの長い問題なので、並列化とかでそれなりに乗り切れる。
２つ目のパターンは、真面目に考えないといけないむずかし目の仕事。 うーんと考える。既存のコードやインフラのドキュメントを読む。方針とかを書き出して関係者の反応を見る・・・など、 コードを書くためのコード以外の準備がそれなりに必要なもの。
個人的にはこの２つ目に手強さを感じている。 自分は考え事や調査に時間を溶かしがち。しかも考え事をするとコードを書く勢いが止まってしまう不安がある。 気がつくとまた雑用の引力に引き込まれてしまうんじゃないか。
そんな気の重さに負け、つい優先度の低い細かいリファクタリングやバグ修正を優先してしまったりする。 でもそういうことをしていると大事な問題が前に進まない。
世の中の WCED 体験談にも、似たような意見を見かけることがある。 WCED はもともと課外活動のためのアイデアなので、それなら WCED を目的にして手段を調整すればいいといえばいい。 課外活動の WCED はそうやって問題を回避している。たとえば coding quiz や教材を優先する、みたいな。 でも自分は仕事をはかどらせるのが目的なので、同じ方法は使えない。
仕事に WCED は無理があったのか、それとも自分の仕事の仕方がよくないのか。 みんな仕事で毎日コードかいてんの？どうなの？