It depends. People were reluctant to give up a lot of bad coding practices (goto, variable scoping, writing in efficient assembly rather than a high-level language, mutable global state) until the better way had better tools or was taught better.
Edit: Maybe one day people will look back and say, "you shipped code without formal correctness proofs? Were you all high?"
There is code that pushes the boundaries of the human mind, complex systems that cannot have any additional complexity if they are to succeed.
And there's other code that pushes against physical or economic limits: processor speed, memory available, network latency. In those systems, writing in an inefficient, high level language is just as wrong as writing the first type of code in a low level one.
Fast, complex, difficult to fully verify code is not bad coding practice any more than a rocket is a worse vehicle than a Volvo because it explodes more. Volvos can't go to space.
But one day our skill in "controlling explosions" (bad logic) may be as good as our skill at doing so in a Volvo, where we can get the power, with the efficiency and predictability.
News at 11: winging it is less work than being careful!
(Of course, the situation gets fuzzier when you must account for other factors: work/dollars/lives lost due to bugs in dependencies, the integral of maintenance costs over time, etc.)
Right. The tools don't need to be easier than competitors, they just need to be easy enough and provide enough benefit that doing it another way isn't worth it.
It's your job as a worker not to cut corners. It's their job as a manager to fire incompetence. Needless to say I think everyone is failing to do their job.
