They let anyone commit to production these days

Today, more than ever so it seems, people outside the software engineering field partake in writing code that eventually makes it to production environments. An increasingly great number of companies have data analysts or researcher personnel write code as part of their job.

I find this phenomenon rather interesting as I do not believe this was the case as far as only a decade ago. Back in the day, doctors practiced medicine, chefs practiced cooking and researchers practiced, well, research. It was the software engineers who were concerned with how to get computers do what was needed to be done using code.
Today on the other hand, while it’s still quite difficult to find a brain surgeon who writes code, it is quite easy to find a computer vision researcher coding for a software company, or a statistician slamming hadoop jobs (the reason for this shift is interesting in its own right, but as design documents often state – this is out of scope).

At first sight more people writing code could imply a great productivity boost. The thing is, software engineering is a profession (I'd even risk saying art). There are things to know in order to be able to make good software - technologies, frameworks, design patters, architectural considerations, coding conventions, tools, and whatnot. In fact, it is only natural for people whose main occupation is not software, to NOT be aware of most of the above mentioned. What’s unnatural, at least to me, is for an organization to ignore this issue and let such code be committed to a production codebase as if it stood up to the standards of genuine production code.

The cost WILL be payed, it's just a matter of time. Someday one will take a look at that module and realize it has no documentation or comments, its methods span hundreds of lines, the logs are written to proprietary files waiting to blow the disk up, there's zero modularity, zero unit tests, but plenty of code duplication (because that part that does matrix multiplication is used in several places, obviously). What’s to be done now, one would ask himself, I can’t just re-write the whole thing. Right, I guess that’s how a legacy (system) is born.

As fate would have it, the bug that will trigger this chain of events will probably be one of those must-fix-by-yesterday bugs that just must be resolved yesterday, or ASAP, whichever comes first.

As products mature, maintenance becomes a considerable part of their agenda, and that's when the quality of the codebase kicks in and becomes a key factor. What was once a boost has now become a major drag. 

A question to be asked here is how can we bridge the gap between the code quality required in production and the code quality produced by research oriented specialists (who are not software engineers) in our organization? 

• Should everyone who’s to engage coding get training? What training would that be? Are people expected to be proficient both in their main occupation (say statistics) and software engineering? Isn't that like saying they need to have two professions (does this mean they’ll get two paychecks?) 
• Should that code be re-written from scratch by software engineers? That could easily double the efforts...
• Should such code be written using pair programming where one is a software engineer and the other is a domain professional? 

Makes one wonder…