3 ms·
Structure is great for a well understood problem space, but this is not usually the case when working working something novel. As a researcher your focus should
by brakus127 6y ago
Structure is great for a well understood problem space, but this is not usually the case when working working something novel. As a researcher your focus should be on learning and problem solving, not creating a beautiful code base. Imposing too many constraints early on can negatively impact your project later on. In the worse case, your code starts to limit the way you think about your research. I agree that there are some general best practices that should be applied to nearly all forms of coding, but beyond that it's a balance.
The same thinking should be used when adding regulation to an industry. Heavy regulation on a rapid developing industry can stifle innovation. Regulation (if needed), should be applied as our understanding of the industry increases.
- bordercases 6y agoResults need to be refined so that the way they were first formulated doesn't get in the way of their replication. At scale, this too becomes a cost to industry. In the small, this isn't different from taking a lab notebook and making it clearer and better summarized so that it can be passed on to the poor sucker who has to do what you did after you move on to another project. Furthermore, software projects that are put under the same iterative stress you imply for R&D inevitably go through a refactoring phase so that performance isn't affected in the long run.
- brakus127 6y agoAgreed that there should be a minimum bar for "completed" research code such as reproducibility and a clear summary, but engineers shouldn't expect the first version of a new algorithm to be easy to understand without additional material or ready for production without a complete rewrite.