美しいコードを書くことが目的にすり替わらぬよう。

こんにちは。

今日の結論としては、

目的のある仕事を分割して、

タスクごとに倒していくやり方はすべき、

ただ、小タスクにのめり込んで大目的からブレがち。

大目的はなんだっけ、と何度でも思い出すことが

必要ということです。

データサイエンスの業務は困難の森

解くべき課題設定ができた。

試す仮説が決まった。

その後、データを加工して、可視化したり、

モデルを作ったり、、というフェーズになるわけです。

ここで、プログラミングをゴリゴリしていくフェーズに

入ると、小タスクにのめり込んで大目的からブレる、

これが起こりがちに感じます。

・汎用性のあるコードにしておこうと、ちょっとした

反復処理の綺麗さに拘ってしまう

・applyでデータフレームを処理しよう。applyでどんな関数を

書くべきか、悩んでしまう

・グラフの可視化で、美しい見た目、漏れのない判例や軸の表示に

拘ってしまう

・グラフを綺麗に複数並べるため、subplots絡みの処理で沼に

ハマっていく・・・

などなど。

どれも、こだわって遂行すること自体は、悪いこと

ではないです。

しかし、アルゴリズムやグラフの綺麗さって、

追求すると終わりがない。

時間の制約を無視すると、いくらでも作業できてしまう。

ここに、罠がありますね。

時間の制約、大目的から、やるべきことの優先順位判断が必要だ

実務では、必ず時間的な制約があるはずです。

そして、今やっているプログラミングも、目的を持った

タスクだったはず。

そうすると、時間の中で、最低限満たしていないといけないことは

なんなのか、考えて計画を立てる必要がある。

実装の作業だと、大抵は一人作業になりがちと思います。

自分で判断して、「次の報告で求められている趣旨はこれ。だから、

グラフは簡素でも良い。」など見切りをつけることも、スキルと

思います。

また、人に途中途中、状況を報告してフィードバックもらうの

良いですね。

自分がこだわり抜こうと思って時間かけていたところ、

あっさり、「今やることと少しずれてきてない？？」と

指摘をもらえることがあります。

ついつい、実装者側だと、美しいコードを書くことが目的に

なりがち。しかし、今の目的は、課題を解くのに必要な

結果を出すこと。

客観的に見てもらうと、自分自身で書いているコードという

愛着抜きに、指摘してもらえるので良いと思います。

今日は、特にコードをゴリゴリと書く日だったので、

ついつい「コードのためのコーディング」に

なっている自覚があり、備忘録として記します。