体系的に勉強するべし

ワークアラウンド大いに結構。でもそれが本当にワークアラウンド足り得ること、望まぬ副作用を生じさせないことはどうやって検証する?アセンブリで追っかけるのと同等の環境の実装に対する深い理解が必須じゃないの?

UNIX 系のプログラマなら POSIX、Windows 系なら Win32API を把握していればいいんじゃないでしょうかね。組み込みとかメインフレームとかは良く分からないです。
でさ、アセンブリレベルの知識がないと解決できない問題って良くわかんないんですよ。正直。たとえば Python プログラマが Python インタプリタの奇妙な動作を発見して、じゃあそこでやることといえば、

• C のソース自力で修正
• Mailing List に Post するなどコミュニティ(もしくはベンダ)に通知
• 対外的な振る舞いを観測してワークアラウンドを仕込む

くらいだと思うんだけど、で、自力で修正した場合、他に副作用が出ていないことはどうやって確認するの？Python インタプリタを修正するには Python インタプリタに関する深い知識が必要でしょ？仮に修正できたとして、それは Python プログラマとして成長しているの？
時間は有限なんだから、スキルだってある程度のところで切らないと切りがないよ。私もライブラリのバグに遭遇して自分で fix したり、作者なりコミュニティにレポートしたりすることもあれば、外部からの挙動を観察してワークアラウンドを入れることもある。それは自分のスキルと時間に応じてやるしかないわけですよ。そこで、求められるスキルってのは現場によりいろいろ違うんじゃないかな。

んで、前のエントリでも書いたけど、その基礎体力、言い替えるとリテラシを養うためにはマシン語の習得は効果的だ、というのがこちらの主張な訳だけど、ここで改めてマシン語の習得に否定的な方々にお伺いしたい。そういう基礎体力を養う、つぶしの効くソフト屋になるための方法で、マシン語の習得よりも効果的な方法ってなんだろう?皮肉とか変なレトリックじゃなくて、アイデアがあれば本当に聞きたい。

本読めば？パタヘネでもヘネパタでも。読んだこと無いけど。というか一実装系をいじったことがあるくらいで理解したつもりになられるほうが困ると思うんだけどいかがか。Single CPU の x86 でいくら経験をつんでも、incl がアトミックでないことはわかんないでしょ。分岐予測ミスのペナルティがでかいとかデータと命令には局所性があるからキャッシュメモリが有効とか、SMP 構成でキャッシュメモリの働きが云々とか、メモリオーダの問題があるから double-checked locking は駄目とか。逆にこれらの知識って実装を知らないと駄目かってそんなことはないと思うんだよね。それこそ、モデルに関する理解のほうが重要なんじゃないかと。