I am a neuroscientist and a good portion of my laboratory's scientific output is code. I can offer a perspective. Every few months, a case like this one emerge

I am a neuroscientist and a good portion of my laboratory's scientific output is code. I can offer a perspective. Every few months, a case like this one emerges. A published software contained a scientifically relevant bug and this may have had an influence on other studies that used that software. The reaction is always the same: blaming the naivete of the researchers because they are not professional coders. While I would certainly love to see more interaction between professional coders and scientists, I don't agree with the overall sentiment. I find it counterproductive and even naive for several reasons: 1) mistakes happen. Wikipedia has a long and certainly not complete list of software bugs that had major consequences ( https://en.wikipedia.org/wiki/List_of_software_bugs https://en.wikipedia.org/wiki/List_of_software_bugs ) and most of them come from professional coders in all kind of industries. There is no doubt whatsoever that code produced by scientists is in generall less streamed, less reviewed, and way uglier but is it on average more buggy where it matters? Unless we answer this question, the discussion is moot. 2) Scientists who produce software by themselves do this according to Open Source philosophy meaning that the code can be scrutinized by anyone. I'd rather use a possibly buggy but open-source software over one that I cannot even scrutinize. I think published results should only be accepted if they rely on open-source software: we would never accept a figure of a paper unless the protocol was 100% disclosed. This is one aspect where we can all immediately act. As a reviewer, I will never accept a paper that made use of new software unless the code is an integral part of the paper. I urge all my colleagues to do the same. Also, as authors, if you have to write software from scratch, take code readability into account exactly for this reason. Python is a good choice for this reason. R much less so. 3) we must encourage scientists to take on more coding, and not the opposite. If we keep telling them that they are not going to be good enough, we are not helping. A the moment the trade-off is very clear: either not-professionally coded software or no software whatsoever. Fields like crystallography have shown that the former option can still be extremely favorable.