I've worked at a couple of companies where this was a winning strategy, but I've worked at more companies where attempting this sort of thing on a regular basis

I've worked at a couple of companies where this was a winning strategy, but I've worked at more companies where attempting this sort of thing on a regular basis will cause problems that are more complex and "worse" than being fired. At a lot of places you'll have a small group of really talented engineers who would all support the idea of doing "the right thing" even if it flies in the face of established process, and then you have everyone else, particularly people on other teams (sales, QA, project management, general management -- but sometimes also engineers that have grown accustomed to the familiar process, even if it is objectively broken), who will fight you tooth and nail on any deviation from the process simply because "that isn't how we do it here" and the end result is usually that you end up in a situation where you don't get fired outright (if you're recognized as a great developer, it usually takes quite a lot of boat rocking for you to actually get sacked), but things get politically poisonous to the point where even the engineers who support you in theory just want you to stop to ease the tension being created. As others have mentioned, this advice is very situation and probably serves people much better in companies that are smaller or that at least have a more dynamic company culture. At many companies you'd save everyone (including yourself) a bunch of time and heartache by just quitting when the process becomes unreasonable and entrenched.