4 ms·
Exactly. The C++ code in the GitHub repo is absolutely frightening, but I'm 100% sure if would be pretty much the same in e.g. Python, probaly even worse. From
by w0utert 6y ago
Exactly. The C++ code in the GitHub repo is absolutely frightening, but I'm 100% sure if would be pretty much the same in e.g. Python, probaly even worse. From my own experience code quality is inversely related to barrier of entry, which means I see a lot more terrible MATLAB and Python code than terrible C++ code.
The only conclusion you can draw from a repo like this, is the conclusion I've drawn countless times when the next piece of modeling code developed by some math or physics expert lands on my desk: these kinds of things can not be developed by domain experts alone, you always need to include skilled software engineers to translate the prototypes they develop (preferably in something like MATLAB) into production code.
- tensor 6y agoHow do you propose identifying these "skilled software engineers"? University doesn't teach "professional software engineering" so all these hotshots coming out of school into industry can't be what you're looking for. There is no standards body defining the skills one needs to be considered professional. There is no responsibility on practitioners unlike other engineering professions. If a mechanical engineer screws up and causes death, it's going to be bad for them. Software routinely screws up with no consequence. Hell, take two "software engineers" from FAANG and give them a piece of code and they won't agree on whether it's good or bad. None of this is to excuse poorly written scientific code, but if "professional software engineers" want to throw rocks, maybe they should fix their own glass house first.
- zanew101 6y agoI work in an research setting with access to lots of skilled software engineers and I've come to a very similar conclusion. The problem I often see is that there is very little incentive for the researcher to bring a software engineer onto their project unless it is absolutely necessary. It is just now becoming commonplace to release code when you publish and plenty of researchers still don't. If you think no one is going to see your code then it makes it much harder to care about its quality. One way we've been fighting this internally is by trying to get researchers less silo'd and more open to code reviews. Once a code review is part of the process then bringing on an "expert coder" to address some of the issues that come up in the reviews has more tangible results! We've seen some success in improving our code quality with this strategy.