こちらによく書く話に近いんですが、今回はQiitaに書きました。
13000字・・・・・・
言語化して、色々気づきが合ったので良かったと思います。
わからないことをわかるようにするプロセスは案外ルーチンワーク化できるかもしれません。
- エンジニアリングにおける「わかる」ためのフロー
- 「わかる」とはどういう状態か
- 目的が生じたときの解決プロセス
- プログラム、開発で考えると理解しやすい
- 新人はどのようにしてプログラミング的思考に到達するのか?
エンジニアリングにおける「わかる」ためのフロー
はこういう感じだと思います。
よくもまあこういうフローを無意識で普段やってますよね。人間って不思議。
「わかる」とはどういう状態か
は下図のようなんですが
似たことはずっと考えてました。
ここらへん子供の頃から考えてる気がします。
目的が生じたときの解決プロセス
も言語化できてよかったです。
案外シンプルなんですが、ここに気づくのに結構時間がかかる気がします。
ちなみに現実の業務だと要素が増えます。例えば納期とか予算とか。
プログラム、開発で考えると理解しやすい
面白いのは、現実の複雑な振る舞いやプロセスを、プログラムという仮想上で再構築しているので、現実の複雑な振る舞いやプロセスを理解するのに、プログラムで考えると理解しやすいということです。
プログラムもそうだし、開発業務そのものもそうです。
科学的手法というのは残った理想と現実とのギャップを埋めるための最後の武器という感じがします。
プログラミング的思考って多分ここらへんの話ですよね?これを誰かに教えるというのは非常に骨が折れそうです。
例
新人はどのようにしてプログラミング的思考に到達するのか?
こういう技術は高校生までは「小賢しさ」として認識されると思います。
既に体系化された知識を学ぶ勉強・暗記が是ですから。その思想に誰であれ多かれ少なかれ毒されます。
それでもあまり毒されず、科学的手法・実験的手法が好きな小賢しい奴らがプログラマーになってるのではないかと思います。つまりプログラマーになってから覚えてる人は少ないのでは?という疑いがあります。
でもそういう曖昧な部分ってプログラミングという文脈では悪ですよね。詳らかにしていけたほうが良いと思うんですが、如何せんここの領域に興味を持ってる人が少ない感じがします。たぶん新人はまだまだ苦しむのではないでしょうか?
まずこれらを体系化できたとして、新人がマスターできるのかはよくわかりません。どうなんでしょうか。