アカウント名:
パスワード:
本物のプログラマになるための必須事項だと思いましたね。タレこみがなぜこんなにネガティブなのか、そこが最大の疑問。
記事で指摘されている項目って, 実際にプロジェクトで各種のツールを理解する上で必要になることですね. このあたりを把握していると, ツールを使う際に採るべきスタイルや避けた方が良い機能なんかが事前に予測できますし, ツールの使い方を完全に覚えなくても使えたりするとか.
一方, そうしたスタイルやルールを天下り的に受け入れる立場だと, そうしたknow howをいかに多く記憶するかが勝負で. 開発基盤が変わらないのであれば, know how重視型はリニアに開発効率に結びつくので好ましい戦略と思われるのかも.
でも, 開発基盤が変わることを前提とするなら, know how重視型は再教育のコストが大きいので不利なんですよね. 下手すると古いbad know howを捨てられずに, いわゆる老害になったり. 言い方を変えればツブしが効かないってやつで.
短期のプロジェクトで使い捨てが前提のプログラマなら, know how型の促成栽培でかまわないと思いますが, 将来の未知の環境に対応して, プロジェクトのスタイル等を決める上級プログラマを育てるのであれば, know why型の教育が必要でしょう.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
記事に完全に同意 (スコア:0)
本物のプログラマになるための必須事項だと思いましたね。
タレこみがなぜこんなにネガティブなのか、そこが最大の疑問。
know howとknow whyの違い (スコア:3, すばらしい洞察)
記事で指摘されている項目って, 実際にプロジェクトで各種のツールを理解する上で必要になることですね. このあたりを把握していると, ツールを使う際に採るべきスタイルや避けた方が良い機能なんかが事前に予測できますし, ツールの使い方を完全に覚えなくても使えたりするとか.
一方, そうしたスタイルやルールを天下り的に受け入れる立場だと, そうしたknow howをいかに多く記憶するかが勝負で. 開発基盤が変わらないのであれば, know how重視型はリニアに開発効率に結びつくので好ましい戦略と思われるのかも.
でも, 開発基盤が変わることを前提とするなら, know how重視型は再教育のコストが大きいので不利なんですよね. 下手すると古いbad know howを捨てられずに, いわゆる老害になったり. 言い方を変えればツブしが効かないってやつで.
短期のプロジェクトで使い捨てが前提のプログラマなら, know how型の促成栽培でかまわないと思いますが, 将来の未知の環境に対応して, プロジェクトのスタイル等を決める上級プログラマを育てるのであれば, know why型の教育が必要でしょう.