プログラムを書いているとすぐに解決出来ないことがある。その時にどのようにふるまうかが経験の差として表れると思う。 プログラムでExceptionが起きたときは、早く解決しようとしてしまうし、境界や軸を設定しない。その結果としてコーディングに余計に時間がかかるんじゃないかと思うようになった。
早く解決しようとするのは、問題をしっかり見ようとせず、エラーは良くないものだから早く解決しないといけないと考えてしまうからだと思う。
最近面白い記事を読んだ。この投稿はアプリやサービス開発の文脈だけど、プログラミングでコードがうまく動かなくてやみくもに触るような状況にも当てはまる。問題が起きるまでの流れを理解するのは時間がかかるのでフィードバックがほしくてどうしても闇雲にトライをしてしまう。
When & Why to Explore the Problem Space
It is difficult to fit deep understanding into the speedy time frame of development
筆者が提唱するのは、問題空間と解法空間を分けること。それはLEANなどで提唱されているのだけど、筆者はさらに、問題空間と解法空間の間に戦略、Strategyを入れることを提案している。問題や理論をしっかり理解することで、どのように解決したら良いかが分かるようになると思う。
また、境界や軸は、動かせない条件、引数や型でこれが決まってないとあっちこっち触って結局プログラムが動かないということになる。
また、ポモドーロの本でこんなことが書かれていて、時間の使い方、焦りをどう解決するかというより大きな話につながると思う。
ポモドーロ は 抽象的 な 時間 を 表す。 ポモドーロ は「 時間 の 生成」 を 制限 する 箱 だ。 この 時間 の 生成 に対する 依存 を 断ち切り、 それ を 反転 さ せる こと によって 時間 を 別 の 観点 で 捉え られる よう に なる。
フランチェスコ・シリロ. どんな仕事も「25分+5分」で結果が出る ポモドーロ・テクニック入門 (p.164). 株式会社ＣＣＣメディアハウス. Kindle 版.
UnsplashのTowfiqu barbhuiyaが撮影した写真
