Do "research software engineers" make good candidates for quant research positions?

Daniel Duffy

C++ author, trainer
It all sounds a bit fuzzy
  1. Are you employed to develop software for research?
  2. Are you spending more time developing software than conducting research?
  3. Are you employed as a postdoctoral researcher, even though you predominantly work on software development?
  4. Are you the person who does computers in your research group?
  5. Are you sometimes not named on research papers despite playing a fundamental part in developing the software used to create them?
  6. Do you lack the metrics needed to progress your academic career, like papers and conference presentations, despite having made a significant contribution through software?

This has nothing to do with software; it is an organisational problem.

Point 4 is strange..
I phrased this question poorly. My specific question is as follows: a research software engineer (RSE) is a relatively new name even though the concept has existed without this name for a while. In summary, an RSE is someone who writes (readable, reusable and maintainable) code to facilitate scientific research. Has the name "RSE" been in circulation in professional circles long enough for them to see RSEs as good candidates for quant positions? Can you also expand on what you mean by "Yes"?

Sorry for the manifestation of the GIGO principle...

Daniel Duffy

C++ author, trainer
In my 45 years in software I have never heard this term before. It is pure fantasy.

RSE is someone who writes (readable, reusable and maintainable)

They are looking for someone to clean the mess?


"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems."
-Brian Foote and Joseph Yoder, 1997
Last edited:

Daniel Duffy

C++ author, trainer
“As time passes, the system becomes less and less well-ordered. Sooner or later the fixing cease to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. ...A brand-new, from-the-ground-up redesign is necessary.”
― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering