One of the hard lessons in the transition was realizing that things that allowed me to work more efficiently when I was a software engineer instead reduce my efficiency in my new career.
You might get a decent analogy of the difference by comparing photographs of the first transistor with pictures of every subsequent transistor. The first transistor's clearly going to be terrible in any production application. But the same characteristics that make it so terrible for practical use were also, to varying degrees, essential to or characteristic of the exploratory process that led to its creation.
It's similar for my R&D code. In order to do my R&D work more efficiently and effectively, I need to do things that would be unholy in production code. This is why there's a separate and essential productionizing step where my output is heavily revamped and possibly even completely rewritten in a different programming language.
re: repeatability, I've discovered that it, too, means something slightly different in a science context than it does in an engineering context.
The added bonus is you get science that's you know, repeatable. Because the difference between industrial code and prototype code is that it gets run so often there can't be glaring mistakes; it must be repeatable by default. We have different techniques for dealing with these problems, but writing good code is orthogonal to that (I don't think scientists need to be running static analysis, doing deep reviews, and having extensive integration/unit/mock testing throughout their code).