電車内プログラミングの生産性が高いのは何故かに関する考察

Twitterから転載

電車の中でやるコーディングは自由意志でやりたいと思ってやるコーディングなので生産性が高い
電車の中ではインタラプトが入らないから生産性が高い
近づいてくるデッドラインが明確なので締め切り効果が発生して生産性が高い
電車の中では調べ物ができないので、調べ物が必要なタスクが後回しにされて、結果として下調べが済んでいるもしくは脳内の知識でできるタスクを実行するから生産性が高く見える
タイミングが予想出来る乗り換えインタラプトが存在するので、乗り換えの間に考えていたことを忘れないようにファイルに出力すること、そして歩くことが問題の整理に役立っている
電車の適度な騒音や移動していることによる海馬への刺激がなんか集中力を高めたりするのかもしれない
「目的地につくまで15分だからその間にアレを実装出来るかな？」というのがまさに「自発的に設定した制限時間へのチャレンジ」なのでドーパミンが出る。脳を活かす勉強法にそれをやると脳にいいって書いてあった。
単に今までの電車コーディングor電車内読書の習慣が原因で「電車内=強い没入」という刷り込みが行われている
少し視点を変えて、なぜ騒がしいところは同じだが、興味をひかれる話もあって没入しにくいJava-ja温泉で高い生産性が発揮できたのかを考えると、何をやっているのかわかるようにTwitterに進捗を垂れ流したのが原因かもしれない。つまりインタラプトが高頻度で入ることを予想していたがために「インタラプトが入っても何をどこまで考えていたかわからなくならないように細粒度で思考内容を外部記憶に記録」という戦略をとったところがよかったのかもしれない。
電車の中で着手しようと思う程度に、すでに細かい単位にタスクブレイクダウンが完了しているタスクだから生産性が高い
制約があることで必要条件や今できるできないなどでタスクのブレイクダウンが進む。「ある機能を実装する」ってタスクからが「bit.lyのAPIの使い方を調べる」が切り出されたり。
電車の中での作業なのでデプロイなどの待機時間が発生するタスクではない。逆に言うとコンパイル時間が長いタスクをやったら生産性が低いのか？？
乗り換えインタラプトで考えていたことを忘れてしまうリスクの回避の一環として手元のリポジトリに細かい機能単位でコミットしている。それが達成感を高めて背中を押すのか？
電車の中なので社内掲示板、Twitter、Lingr、IRC、Skypeなどの脳内スレッドが全部sleepしているのでコンテキストスイッチが起きない
逃げ場所がないから集中する以外にない