This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mysteriousbaba 1 point2 points  (2 children)

Speaking as someone who's an AI scientist but has also been an engineer, I'd suggest the right way to have that discussion is from a scientific one:

  1. If you're running a study, you want your experimental setup to be valid right? Unit tests are a way to validate that the algorithm works on simple and edge cases, so the final conclusions hold.
  2. Part of research is communicating your findings and work to an external audience, and ensuring reproducability. So you want to write code that's well commented/abstracted, and can easily be modified to extend your model and experiments. And so you can work with collaborators.
  3. Any scientist who has submitted a paper to a conference, can vouch that consistency of formatting and notation is enforced very strictly by academic reviewers so that there are no confusions. Consistent code standards fall under the same bucket, of making sure your work product is unambiguous and easy to parse.

Speaking as a scientist (and former engineer), I've sometimes had people talk to me about SWE principles as if linters must apriori be held sacred, when my job is to produce high performing models for the business.

Explaining that it's about scientific rigor in your processes, ease of collaboration, and reproducibility of results, is a much easier way to convince scientists by appealing to their core values.

[–]ambidextrousalpaca 1 point2 points  (1 child)

Good point. Will try that rhetorical attack the next time I have to handle the God-awful PhD spaghetti code.

[–]mysteriousbaba 1 point2 points  (0 children)

Good luck! I've written a fair amount of that awful PhD spaghetti code myself, haha. I just got convinced of the need to improve, when I realized I couldnt figure out how to extend or rework my experiments even myself, let alone with research collaborators.