去年はストレスと雑用に負け仕事でコードを書かなすぎた反省があり、ここ一ヶ月くらい「午前中は他のすべてをほっぽらかしてコードを書く」という方針を試している。

コードを書かないのは、バグを睨んだり人のコードをレビューしたりメールを書いたりバグを睨んだりしていたから。プラスそういう盛り上がらない仕事によって procrastination が倍増したからな気がする。

コードを書くようにするという方針にして以来、仕事は捗るしプログラマとしての満足度も高い。よい。続けたい。

が、続けようとすると問題もある。つまり、ある種のコードを書くには割と準備が必要である。その準備は API や既存コードベースの調査かもしれないし、でかめのプロジェクトなら計画みたいのもある程度は必要だし、他人のコードをいじるならそれなりに話を通す必要がある。ざっくりいうと「考える」必要がある。コード書くのは考えないのかといわれると困るけど、コードを書きながら試行錯誤をして考えられる問題と、もうちょっと違う次元で考えないといけない問題がある気がする。特にドキュメントや既存コードを読んで理解するというのは本質的に何も生産してない。

今はそういう問題は後回しにしてコードを書けそうな仕事を優先的に片付けている。それは、ここ一ヶ月くらいは機能してきた。ぼんやりめんどくせーな、とおもっていた仕事もいざコードを書いてみれば一瞬だったりで、成果には満足している。ただ昨年から持ち越した小物はさすがにだいたい片付いてきて、大物ばかりが目に付き始めた。どうしたものか。

一つのアプローチは、諦めて朝から準備作業をする路線。これは会社員的には正しい気もするが、「毎日コードを書く」というルールが失われ、もとの状態にもどってしまう気がして気が乗らない。

逆に「コードを書く」というしばりを優先し、低優先度の小物でも半趣味的コードでも書くものをさがしてがんばる、という路線もある。ただこれをやってると大物のために考える時間がとれない気もする。

午前中の「コードを書く」しばりを残しつつ、午後に計画などの準備作業をすることはできるか。やや不安がある。まず日々のルーチン的雑用を無視できるのか。コードレビューとかバグ分析とか、ほっとくのは気が引けるし、待ってる人から直接つつると現実的に無視できないじゃん。あと午後はミーティングから子供まで割り込みの発生頻度が高く、時間の枠として立ち入った考え事をするのに向いていない面もある。

妥協案として「午前中」はあきらめ、コード書きタイムをたとえば「十時半まで」とかにしてみる。あるいは「月水金の午前中はコード」とか？まあ、アリかもしれない。

「小物でも半趣味的コードでも」という部分への不安もある。ちゃんと成果の出るコードを書かないとだめじゃね？仕事すすんでなくね？そして成果を出そうとするならコードの前に頭つかう時間は必要なのではないか。

計画や準備のような「頭を使う」作業を、プログラミングの支援を通じて進められないか。よく「高級言語のプログラミングはデザイン」みたいな話あるじゃん。あるいはプロトタイピング重要みたいな。そういうノリで進められる仕事はないのか。

手元のプロジェクトリストをみると・・・上から順に: なんかのトレースをとって分析する、なんかの proposal を書く、自動テストの機能追加に向けて他人のコードのリファクタリング。うーむ割と本質的に paperwork だな・・・。リストの先にいくともうちょっとコード書けるっぽいやつもある。うーむ。

一歩さがると、ここでいう paperwork とはコード仕事を「作る」作業といえる。

• トレースを睨めば遅いところが見つかって、それを治す仕事が発生するかもれない。
• ある proposal を書けば、そのアイデアは PM の後ろ盾や関係各所からのインプットにより大きなプロジェクトすなわちコードを書く機会につながるかもしれない。
• リファクタリングを構想して話をつける作業は、そのコードの ownership を獲得してその後のコード書きをやりやすくするかもしれない。

理想的には、自分の仕事が「コード書き」と「仕事生成」からできているのが望ましい。これは、Cal Newport 用語でいう Deep Work である。しかし現実は「雑用」と「雑用以外」というカテゴリわけになっており、「雑用以外」すなわち deep work の時間がに少ないのが本質的な問題である。

と考えると、ひとつの方向性はこの「雑用」すなわちバグ睨みなどをへらすためにコードを書き、雑用の負荷を下げることではないか。これは第三の方向性といえる。

雑用負荷の軽減は前からぼんやり考えているんだけれど、こういう生産性改善プログラミングってすごい投機的で失敗するとほんとに何も残らないのが厳しい。本業じゃないから仕事をしたフリにすらならない。そしてしばしば技術的官僚性が手強すぎて倒せなかったりする。EngProd (世間でいう DX) が専門職になってるのは理由があるわけ。あんまり近づきたくない。リスク高すぎ。

うーん。こういう抽象的な議論は目先の問題を片付ける役には立たないね。まずは時間割を妥協し、かつ prep work の中にコードを探すというかんじかなあ。

ついでに Message Passing で聞いてみるかなあ。