私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。

なのに

ここ/.に集う開発者で、自分の企業を説得して「カウボーイ風コーディング」を止めさせるか縮小させるかし、ベストプラクティスを導入させるのに成功した人はいませんか?

というのは何か間違っている。

この人の場合、２つの異なる障害があって、それが複合的にプロジェクトの息の根を止めていると思われる。会社を直すのはより時間が掛かるので、まずは自分を治すことからはじめるべきだろう。

プログラムが『バギーで、遅くて、脆弱で、保守するのも一苦労』な状態になるのは、

・熟慮されたアルゴリズムを用いず(バギー、遅い)
・計算量を事前に予測せず(遅い)
・例外が多く(バギー、脆弱、保守が大変)
・目の前の問題を直せばよい、と修正を最小化使用としすぎるから(保守が大変、脆弱)

である事が多い。これを直すのは一筋縄ではいかないが、

1) まずはアルゴリズムの勉強をする
2) 特に「計算量」の勉強をする
3) アルゴリズムの勉強には「マクロ」レベルからビット操作などの「ミクロ」レベルまであるが、その全てを勉強する事で「例外」を減らす
4) 常に「問題の本質」について考え続ける(症状消しをしない)
5) socket プログラミング、multi thread など、マニュアルを見ただけでは判らない事が続発する領域に関しては、本を読みまくる。他人のコードは「本を読んだ後」の方が良い。腐ったコードの方が世の中には多いので、間違ったコードを覚えてしまう確率が異様に高いからだ。
6) コンパイラ…特にオプティマイザについて勉強する。すると、最近のコンパイラは「わかりやすい記述」をしたほうが最適化が進むことがわかる。すると、「半端に凝った記述」をしなくなる(保守性向上)

というプログラミングの勉強と、

7) コードを書く前に、そのコードが何をするものなのか、文章で書いてみる。で、その通りに本番コードとは異なるプログラミング言語で書いてみる。すると曖昧な部分が判るので、文章を直す。それから本番コードを書く。するとなぜかバグが減る(曖昧な部分が減るため)
8) 明文を書く練習をする

という、実はプログラミング以外でも鍛えられる属性を鍛える訓練を続ける。

結局、知識が圧倒的に不足し、その知識を全てロードしようとすると脳がパンクする所に問題があるのだ。脳の容量を拡張し、マニュアルを見れば判るような知識は捨て、もっと本質的なことを覚えると良い。

二言で言い換えると、「努力不足」「プログラミングを舐めるな」になるんだと思う。