Why we need to create careers for research software engineers
I&#x27;ve interviewed for a number of these types of jobs in the last year or so. The pay is just too poor to even think about it. One large university with a super well-funded and growing medical school in a huge mega-city was looking to hire someone with 5+ years of deep experience in both Python and C&#x2F;C++, as well as some familiarity or past education in statistics and machine learning, to be the software development lead for a set of research groups. They weren&#x27;t willing to go above $90k&#x2F;year.<p>In another case, I interviewed with a school of public health at an Ivy university. It was in a medium-to-large city on the east coast, where the cost of living was certainly higher than national average, but not insanely high. Even still, they were looking to pay in the range of $75k for someone with significant years of experience in the scientific Python stack.<p>Not only does this fail to compare even with start-ups that aren&#x27;t located in major tech hubs, but also when compared against salaries offered by established companies in the same cities, it&#x27;s almost a 2x pay jump (more in some cases), for the same skill set.<p>To boot, these lab&#x2F;university environments tend to have many of the same political issues that any other organization has. Sometimes they are <i>slightly</i> more generous with vacation time and work&#x2F;life balance, but not always. But you are generally also working with a lot of research staff who see &quot;programming&quot; as a nuisance that gets in the way of their research, rather than seeing programming as the medium of expression of their research. So when you lobby for using good tools, good workflow practices, and try to teach people how to write reasonable software, you usually get a lot of pushback that people just don&#x27;t like doing it that way, and since you&#x27;re the super low-status programmer, your opinion generally doesn&#x27;t count for much, even if you can back it up with more substance.<p>You also carry some employment risk when projects are funded by grants. Even large, well-established, multi-year grants can be suddenly changed or reduced when there is significant political change in the funding organizations. And a lot of the universities, at least, are unwilling to hire these kinds of expensive programmers as permanent university employees.<p>You&#x27;d probably have a much better career if you instead went to work as a programming-literate business analyst in some part of the university&#x27;s fundraising &#x2F; business departments.<p>In the end, these places can only afford developers with very little experience, or people who don&#x27;t understand the cost of living differential in the city they are moving to, or I guess are independently wealthy and just prefer to be a low-status programmer in one of these labs.<p>Edit: Another thing that struck me -- in a lot of these university research situations, the programming talent that they need to hire is genuinely just harder to find &#x2F; harder to replace than even the research talent you would be working for.<p>Since there&#x27;s a huge surplus of Ph.D. and post-doc labor, you could staff the domain expert research side of things much more easily than the programmer side -- especially if you need someone who is truly full-stack to do things ranging from migrating legacy research data to a cloud platform all the way up to designing fancy UI demos with d3.<p>If you look at another set of industries where the lower-level contributors are much harder to employ than the manager -- professional team sports -- you see that the market dictates that the lower level experts (the actual players on a sports team) almost always command more salary than the coach. There can be exceptions, like Phil Jackson (but even he didn&#x27;t earn more than his best players) and there will be backup players who earn less. But the general idea seems to hold true.<p>This means that a lot of these scientific labs and universities will eventually have to face the market reality that the domain expert labor is just not worth as much as the software design labor. Or else they can just keep on compromising on the quality of the software and try to hold on to a worldview where scraping by with bottom-of-the-barrel software development is good enough. It might work for them for a while longer, but I doubt it will work for too long.