4 ms·

I don't think you need to worry about more than a few principles - 1. Reproducibility This is very important for scientists so I expect them to know about pac

I don't think you need to worry about more than a few principles - 1. Reproducibility This is very important for scientists so I expect them to know about package management and containers. You don't need to know everything about it. Virtual environments, docker and using a good package manager like poetry (which is just an abstraction over virtualenv) shouldn't take more than a few weeks. Once you are done with the basics, you can learn more as you build. 2. Git and documentation Add another few weeks. They don't need to write good code. They just need to document it which they should already be good at. Optimization, scalability, distribution and other things can be handled by engineers but without documentation, it makes the work a lot harder.

sgt101 7y ago
Every engineering team that picked up a code base has at some point had a meeting where someone starts ranting about how the code that they are looking after stinks and it would be better to rewrite it, or move to some alternative. This seems to be true if the code is the product of one person working for a few weeks or 20,000 people who work for 10 years. A few years ago I had a conversation where the team insisted to me that the extensive documentation and instructions for a package were worthless because "good code is self documenting" the leader of the pack had shiny eyes and banged the table several times. Be cautious, be kind and look for value in the code that you are using - not just problems. Also, consider: if you can pick up a code base (written by someone who knows the science) would it not be more profitable to repair, document and improve rather than demanding that the scientists learn both your skills and your way of doing things? If you conclude the latter, would you (hand on heart) be able to empirically demonstrate that your way of doing things is the right way?
throwaway_pdp09 7y ago
I disagree with "They don't need to write good code". Reproducability is a check that you got the right answer. As you describe it, it's more like a crappy programmer that relies on the testing team to catch his errors rather than be responsible for his own. > and other things can be handled by engineers Due to lack of funding and low pay I think most of them don't have access to software domain experts (aka seasoned programmers)

sgt101 7y ago

Every engineering team that picked up a code base has at some point had a meeting where someone starts ranting about how the code that they are looking after stinks and it would be better to rewrite it, or move to some alternative. This seems to be true if the code is the product of one person working for a few weeks or 20,000 people who work for 10 years. A few years ago I had a conversation where the team insisted to me that the extensive documentation and instructions for a package were worthless because "good code is self documenting" the leader of the pack had shiny eyes and banged the table several times. Be cautious, be kind and look for value in the code that you are using - not just problems. Also, consider: if you can pick up a code base (written by someone who knows the science) would it not be more profitable to repair, document and improve rather than demanding that the scientists learn both your skills and your way of doing things? If you conclude the latter, would you (hand on heart) be able to empirically demonstrate that your way of doing things is the right way?

throwaway_pdp09 7y ago

I disagree with "They don't need to write good code". Reproducability is a check that you got the right answer. As you describe it, it's more like a crappy programmer that relies on the testing team to catch his errors rather than be responsible for his own. > and other things can be handled by engineers Due to lack of funding and low pay I think most of them don't have access to software domain experts (aka seasoned programmers)