Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we need to create careers for research software engineers

scientific-computing.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Why we need to create careers for research software engineers

#61

Post by mbreese »

tensor wrote: post #33
magicbuzz wrote: post #15

Working in research as a software engineer can be very frustrating. I wrote the majority of the analysis code for one of the chapters of the IPCC 5th Assessment and yet was told my name couldn't be put anywhere as I wasn't a 'scientist'. I also consistently see people who have never written much code put in charge of projects where the majority of the work/research is writing software. These projects end up with no c…

Some would argue that no OO use is a good thing (assuming you are referring to object oriented programming). Expanding on this, writing research code is quite a bit different than writing production code. In particular, requirements can change quickly and drastically. This means that very open designs where you don't hide data (e.g. as is common in OO programming) are often the best designs.

Research code is production code and should be treated as such. It doesn't matter if requirements change quickly, you still need to treat it like it's production code... you document, test, and deploy it. And you should include the ability to adapt the code to flexible requirements in your initial design.

Just because you may only use the program once doesn't mean that you can neglect good software engineering practices.

I run into bad code all of the time (some of it mine!) in our research, and it's very frustrating.

Re: Why we need to create careers for research software engineers

#62

Post by tfgg »

As a recently departed academic, to vastly generalize, the only people who are research software engineers are perennial postdocs who don't realise yet that their career is a dead end and they're being significantly underpaid for their skill level. They also won't develop their skills adequately in such an environment, lacking good standards and mentorship.

Academia needs to stop taking advantage and accept that it should pay double, so they can actually hire inwards from the private sector and gain good knowledge and skills, or somehow increase the prestige and power to be equivalent to other PI positions. I don't the latter is attainable [1], and I'm sure plenty of people would be happy to just be paid well rather than leave for data science/finance/building web apps.

[1] E.g. If you're in physics, and not doing physics, you're fighting a losing battle to get respect and that lectureship/professorship. Everyone doing coding as their main job has to pretend to do research as well.

Re: Why we need to create careers for research software engineers

#63

Post by Retric »

tensor wrote: post #33
magicbuzz wrote: post #15

Working in research as a software engineer can be very frustrating. I wrote the majority of the analysis code for one of the chapters of the IPCC 5th Assessment and yet was told my name couldn't be put anywhere as I wasn't a 'scientist'. I also consistently see people who have never written much code put in charge of projects where the majority of the work/research is writing software. These projects end up with no c…

Some would argue that no OO use is a good thing (assuming you are referring to object oriented programming). Expanding on this, writing research code is quite a bit different than writing production code. In particular, requirements can change quickly and drastically. This means that very open designs where you don't hide data (e.g. as is common in OO programming) are often the best designs.

If your research code is a big ball of mud then all it's results are meaningless. And all your research should be rejected by any competent journal. Sadly, journals tend to ignore such huge issues.

But, hey it's not like reproduceable results are important in science or anything.

Re: Why we need to create careers for research software engineers

#64

Post by Qworg »

Eridrus wrote: post #49
tostitos1979 wrote: post #36

Earlier quoted context omitted.

Microsoft Research has RSDEs ... research software design engineers. IBM Research also has a research software engineer position, with its own career progression track. These folks are generally fantastic developers who have been professional software engineers some point in their careers. Moreover, I have never personally seen a case where a research engineer was not put on a paper for being just a coder. It is prob…

Correct me if I'm wrong, but my understanding was that being an RSDE at MSR was still a dead-end position. FWIW product engineers usually get bonuses for patents, so there's the obvious incentive of $5k in your pocket.

Things are changing.

Also, if you're on a patent, you get the cube (and the cash).

Re: Why we need to create careers for research software engineers

#65

Post by magicbuzz »

tensor wrote: post #33
magicbuzz wrote: post #15

Working in research as a software engineer can be very frustrating. I wrote the majority of the analysis code for one of the chapters of the IPCC 5th Assessment and yet was told my name couldn't be put anywhere as I wasn't a 'scientist'. I also consistently see people who have never written much code put in charge of projects where the majority of the work/research is writing software. These projects end up with no c…

Some would argue that no OO use is a good thing (assuming you are referring to object oriented programming). Expanding on this, writing research code is quite a bit different than writing production code. In particular, requirements can change quickly and drastically. This means that very open designs where you don't hide data (e.g. as is common in OO programming) are often the best designs.

Any significant dataset should be wrapped with an object. Especially so if multiple scientists/programmers are pulling data from the dataset.

Ever tried multiple algorithm variants? Wrapping an algorithm in an object and then passing it to the data provisioning code means you can be 100% sure that the only thing that has changed in your code is the algorithm.

Re: Why we need to create careers for research software engineers

#66

Post by Retra »

jdminhbg wrote: post #56
xiaoma wrote: post #53

Earlier quoted context omitted.

Limited OO use sounds like a very good thing unless you're building a gui.

It's not "limited OO" in the sense of "well-reasoned FP instead," but rather piles of copy/pasted procedural code.

If you're not doing inheritance (which you often aren't,) a module of well-designed functions does a pretty good impression of OOP.

Re: Why we need to create careers for research software engineers

#67

Post by mbreese »

Retric wrote: post #63
tensor wrote: post #33

Earlier quoted context omitted.

Some would argue that no OO use is a good thing (assuming you are referring to object oriented programming). Expanding on this, writing research code is quite a bit different than writing production code. In particular, requirements can change quickly and drastically. This means that very open designs where you don't hide data (e.g. as is common in OO programming) are often the best designs.

If your research code is a big ball of mud then all it's results are meaningless. And all your research should be rejected by any competent journal. Sadly, journals tend to ignore such huge issues. But, hey it's not like reproduceable results are important in science or anything.

The more computational journals are keeping track of this. I've had a manuscript returned for revision because I didn't have enough unit testing in the code. Wet-lab journals, on the other hand, probably let a lot of stuff go on the computation and statistics than they should.

Re: Why we need to create careers for research software engineers

#68

Post by p4wnc6 »

laurencerowe wrote: post #28
chaosphere2112 wrote: post #9

This is pretty much my job. I develop climate analysis software at a DOE national lab. We have a pretty reasonable career ladder for the "research software engineer". A quick sample: Me: Recent graduate (2012), early career. All dev, all the time. Lead Dev: ~15-20 years experience, minor project management tasks, mostly just dev work. Gets author credit on scientists' papers every once in a while for his help in gene…

I think the organisational structure makes a huge difference. National labs are large enough for there to be a career structure as software engineer. Working in a university 'lab', our jobs are completely dependent on our PI's ability to continue winning grants. The problem space is fascinating (genomics) and the scientists I work with are really great. But as an experienced developer joining the group, it often feel…

But a university (or a department) could manage a centralized set of software developers who get assigned to different lab projects over time. If Professor A's grant goes away, then you just pick up more work on Professor B's grant and Professor C's -- all of which would be managed by the university or department, and not separately managed by each of the professors.

Universities already do this for essential services like janitorial work, administrative work, and centralized IT provisioning, like university-wide email or supercomputing infrastructure.

They even already try to do this to some degree with software. For example, there's been a lot of software-focused hiring at the Cornell Weill school in New York City, and some political science research groups at NYU banded together to hire some big data and development staff to service more than just one professor's line of grant-funded projects.

The problem is that they still fundamentally undervalue software labor and look at a programmer as simulatenously a low-level grunt and a wizard. You're a low-level grunt because your opinion isn't supposed to matter as much as a domain expert's opinion and your 'creative' contributions (in terms of expressing the research idea in software) is supposed to be less valuable than the domain experts' creative work in coming up with the ideas in a more abstract sense. But you're also supposed to be a magic wizard because you're supposed to juggle unreasonable and conflicting sets of requirements, overcome fundamental computational complexity hurdles, and take a bunch of crappy copy/paste code that none of the domain experts are interested in properly refactoring, and somehow make all of that work correctly, reproducibly, and acceptably fast all in time for various paper and reviewer deadlines.

Re: Why we need to create careers for research software engineers

#69

Post by alextgordon »

OopsCriticality wrote: post #52
geebee wrote: post #38

Earlier quoted context omitted.

You raise an important question. It is important to detail the actual contribution, since programming may be perceived as purely implementing an idea with no creative input. That said… in my career so far, I don't think I've ever seen a clean example of coding someone else's idea to spec. If you successfully take an idea from concept to working software, or if a research project requires complex software to be writte…

> You raise an important question. It is important to detail the actual contribution, since programming may be perceived as purely implementing an idea with no creative input. Beyond creative input, there's also the question of liability in case of academic misconduct. I'd question if someone acting in a technician role (say a programming professional) would have a full understanding of the manuscript and so could ac…

> I think we need to be careful about how we define creative contribution; there's a line to be drawn somewhere in there between a creative contribution for the sake of the software (i.e., speeding up execution time by 4x for a simulation running on a cluster) versus a creative contribution that enables the research (i.e., a novel real-time optimization algorithm for electrostimulation). The latter certainly warrants authorship, but I don't think the former does.

So a contribution is only a contribution if it contains an appropriate amount of NIH?

No programmer is going to going to want to work with academics, if they are forced to inject bogus novelty in order to get fair attribution for the real work.

Post reply on HN