レトロゲーム時代のゲーム開発現場では、他社ゲームの解析（ある種のリバースエンジニアリング）を通じ、プログラミングの技術を学んでいた。
ファミコンの他社のプログラムを（当時は任天堂とハドソンぐらいか）解析しつつ、プログラムテクニックを学んだ。当時発売されてたほとんどのゲームを解析した。逆アセンブラもテクニックの向上に合わせて進化した。未知のポートの使い方も分かったし、6502の全ての命令が使えないことも分かった。
今となっては、これには法的な問題が生じうるものの、この発想の基本は、学問上の必須の手続きである「先行研究となる専門書や論文を余すところなく網羅して検証・活用すること」と全く同じである。
現に私が投資価値評価の事業をゼロ立ち上げするに際し、統計モデリングを作る上で、
先行研究はもちろん、隣近所の分野を網羅して、外側からリバースエンジニアリング的な動きをしていた。
一見してバラバラなように思えるが、基礎知識の系統や発展の系譜から逆算していた。
ところで、なぜプログラミングのような系統的な分野は学びづらいのか？
これは、上記のように直接手と頭を動かさずして、系統的に全体像を掴みようがないからである。
これといくらか違う事情があるものの、法学や会計学や数学も、似たような理由に起因する学びづらさがある。
ろくにアップデートされず、読み手が面白がる仕組みのない教科書ばかり、講義は一方通行で講話を垂れ流すだけ、まともに「勉強した」と実感するのは試験対策のみ……。日本語圏でありがちな教育環境に限れば、おおよそこのような経験ばかりの、雑なケースが後を絶たない。
このような対話のない場面からは、中身を自分から検証する余地などどこにもない。
自分の頭を使えて、やる気がある人ほど、つまらなさを強く感じてしまうことになる。
これと逆の面白がれる場面では、「リバースエンジニアリング」の発想が役に立つ。これだけでなく、法学や会計学など、一定の理屈と実践が両輪となってようやく理解が始まる分野にも当てはめやすい。
面白がれる場面について、以下のような「良い」を例として挙げられる：
・法学であれば、売買契約書やNDA（秘密保持契約）や法学史を解きほぐしつつ、民法の条文を比較して眺めてみると良い。
・会計学であれば、貸借対照表・損益計算書・キャッシュフロー計算書のつながりをExcelで組み上げつつ、総勘定元帳と仕訳のルールを眺めると良い。
・数学であれば、計算過程や概念をビジュアライズしている書籍に触れてみると良い。
要は、ストーリーや図形や幾何学に置き換わると言っていい。
（この記事の趣旨から離れるが、既にプログラミングができるなら、部分的にプログラミングに助けを求めるという手もある。)
いずれもフォーマットがかなりカッチリした分野である。
このせいで「どうせ暗記や手続き記憶でしょ？」と言わんばかりの要素が、強調されてしまう。
無味乾燥で行きつまらないためにも、早いうちからヒントやイメージの大枠を得たい。
出来る限り実際の契約書や計数や概念に、生々しく触れておけば事足りる。
そもそもプログラミング学習のためにウェブサービスのクローンを創ったり、先行研究の学習のために論文を再現して実装していくこと自体、リバースエンジニアリングと同じことだと言えてしまうけどね。
boxcox.net、遠藤武。