もしプログラムを教えるとするなら
どんなものが作りたいかを挙げさせてそのためのアプローチを考えさせますかね。
その上で足りない部分があれば指摘するだとか、より効率的な方法があれば紹介するだとか。
で、実際に作らせる。
基本的に、『言語を学ぶ』という目的は非常にモチベーションが小さくしかも学んだあとの応用力が低いです。
言語を学ぶ時、何より必要なのは『モチベーションが高い目的』なんですよね。
『これを作りたいからこの言語を学ぶ』。
結局プログラム言語というのは手段を具体化したツールでしかないんで、それを目的にしてしまうともうどこに走り出せば良いかわからなくなる人の方が圧倒的に多い。
実際、言語特有の機能というのは種々のプログラム言語にそれなりに存在することが多いですけど、正直そこを意図的に避けてコーディングすることも可能です。
だから、あえて使うことで覚えるというのは間違いなんです。
より効率的……言い方を変えるなら、より楽ができる実装方法の一手段としてそういう機能を学ぶというのが正解です。
そういう意味で、より『モチベーションが高い目標』をどれだけ持つことができるかで言語の学習効率というのは大きく変わりますね。
それである程度のものが組めるようになってから初めて、足りないスキルを補い得る課題を出す。
可能であれば、教える人が作った根幹部分とのやりとりを経験させるとさらに良い。
今のご時世、異常な程に作業が早くない限り一つのシステムを一人で作ることはありませんからね。
そうなると、複数人でシステムを組むことになる。
もうひとつ、可能であれば、教える側があえて追加する部分で発現するバグを仕込むことができれば更に良い。
多分、それで自分が作るものの影響範囲と担保という考え方が身につくはずですから。
基本的に今の時代部品を組み合わせて部品を作るという業務がほとんどですからね。
その成果物の動作のエビデンスの取り方というのは絶対的に必要になってくるんです。
まあ、結構な勢いで求められない限りエビデンスをとらない残念な現場もありますけどね。
それって、要するに後から問題が出た場合の保険がないということでしかない。
自分の身は自分で守る必要がある世の中ですからね。
自分でかけられる保険は全力でかけておくべきでしょう。
それができるようになればどこにでも出せるプログラマが完成ですね。
後はもう作りたいものとか、あったら便利なものとかをひたすら作り続けさせるのが良い。
端的に言えば、それで出荷待ちのプログラマの完成です。
