| Used to be a research scientist at a ~3k person Bay Area company. Early versions of a project typically existed outside of the mainline code branch at the company (we usually just tossed it into the company's private gitlab). We tried to keep things reasonably organized and conforming to the company's standards, but as paper deadlines approached the code usually devolved into a mess of technical debt (just like grad school!). After we knew we had some new algorithm or technique that worked, we typically went back and stripped away the cruft, cleaned up the code so it conformed with the company's coding standards, added required tests, pushed to the company's main branch, and began the really hard work: convincing people in the company that what we did was useful for their work to drive adoption. Addressing the specific points: > - researchers conduct experiments that may fail Very true! Often many, many, many experiments... > - they often produce PoC instead of final products This is going to vary a lot depending on where you are working. We were responsible for developing, deploying, and for some time supporting whatever we developed. > - it's tempting to produce tonnes of low quality code (since it just an experiment/PoC!) Yep, especially in early stages. > - often researchers are not software engineers so they don't really care about code quality / tests This really depends on what stage in the lifecycle of a research project we were in. We were responsible for deploying the final code, so at the end of the day it had to be of the same quality as something someone with the title of software engineer would generate. |