Comment by The_Amp_Walrus | Hacker News Reader

Comment by The_Amp_Walrus | Hacker News Reader

Parent Full thread

As someone currently writing scientific programs for scientists, much of the culture of scientific programming is bad and they are having rings run around them by kids who build websites for a living and it's embarassing.

You think web developers are just writing programs for the hell of it? They have operational constraints around their work as well, it's just that there's a rad open online culture of continuous process improvement that's leveling up the tooling and practices that makes what was once hard look easy.

Things scientists using computers can learn from people working in the software industry:

- use a version control oriented workflow

- write extensive tests

- data management, automated data processing/cleaning pipelines, backups

- build generic frameworks

- use continuous integration

- logging and error reporting for long running tasks

- use modern tooling for automating infrastructure and big jobs, rather than manually submitting Slurm jobs via SSH

#notallscientists but the average level of competence is not good and I think the idea that writing software for scientific research is somehow special is backwards and counterproductive.

None of those get you closer to tenure I guess... There used to be research engineers in 'good' labs, friend of mine was. They'd take your software weekly, clean and slice it, help you write tests, connect you with other colleagues or orgs, show you how you could achieve 30x perf when needed, would help you make your shit distributed, would get budget for CI and stuff. That was a dream job for me, for some time, since I'd been mentored by a demi-god of non-destructive-control (radiography, ultrasound...) and radioprotection research that was also a C++-expert sw engineer who had the most beautiful and clean/clear/modular/malleable codebase I've ever seen, and I saw the yuge potential of somewhat even passable sw engineering, especially when I understood his software was used in so many different operational contexts and also advanced research projects without his input, and his colleagues' sw were just toys, toys and more toys.

I don't see that many job posts doing this anymore. And even then it's just not valued that much.

I think the problem is that these academics literally do not understand or appreciate the benefits of having, say, a robust test suite with CI. Software development and DevOps is an alien culture and to be fair a good proportion of software developers themselves don't really get it. It's like a professional lumberjack who regularly sharpens their saw vs a forestry researcher who doesn't realise how slowly they're chopping down trees for samples because their saw is always blunt.

Are you really building generic frameworks and writing extensive tests every time you do some data exploration and analysis in R Studio?

No. You'd be using pre-existing high-level tools for this purpose (in Python land this would be pandas, matplotlib, jupyter etc).

Not all software development should involve writing your own framework, and it's a bit of a trope that junior SWEs try to write DSLs and frameworks where they should just write some throwaway code. That said, if there's a common modelling or simulation method in your field and there's no great open source generic framework for it, then you should take a hard look at what you are all spending your time on (endlessly reimplementing the wheel).

> use modern tooling for automating infrastructure and big jobs, rather than manually submitting Slurm jobs via SSH

Is that going to be robust to whatever new cluster comes along five years down the line, or will it all have to be re-written?

Yes. Rewriting this stuff is much easier when you've already automated it the first time, vs scratching together instututional folklore on how to run a job.

Reply on news.ycombinator.com