90% of my work has been in the Canadian Oil and Gas industry and EVERY company that I've worked for has sought 'get it done' above 'do it right'. In two decades of programming both as a consultant and as an employee I've NEVER had a code review. Even during my two years of Y2K work, whatever I delivered was just fine as long as the end client was happy.
I've inherited systems where the documentation was literally four pieces of 3"x3" sticky notes that covered 'all I needed to know' about 28 in-production apps that I was now the sole supporter of. What was on those sticky notes? The user accounts and passwords for the Oracle database back-ends for the systems and the application names. As you can expect, in-code documentation was non-existent. When I attempted to improve the level of documentation for these systems (even just putting down the 'basics' of the system information on a single sheet of paper), I was threatened with dismissal for being too slow in working with these systems. The other developers who had to interface with these systems I now supported greatly appreciated this additional information as it empowered them and made their work faster, but only a few of them adopted the use of this single-page documentation solution for fear of pissing off the same management that had overseen the creation of this fiasco.
Perhaps I've just been unlucky in my career and I've only stumbled into positions where results always override process, but since I've seen it in small companies, large multinationals and in three levels of Canadian Government, so I suspect that any talk about documenting systems and truly following 'best practices' is just so much BS. What management wants is results ASAP. When things fail it isn't management's fault, yet it is management that prevents systems from being built with adequate documentation and review because that takes longer and costs more, for which they are penalized, and when systems fail, it is the programmer who is at fault, not the manager.
I figured that once I moved into management that I could become part of the solution, but then I found my VP giving me the same results pressure AND the developers who reported to me, ironically, simply wanted the code to be the documentation (The Agile 'the tests ARE the documentation' BS).
Nowadays I simply program for myself and for my direct clients, and this is the only way that I've found to be able to ensure that systems are adequately documented without encountering a fight or threats on my employment.