Published 28th March 2025

Can you introduce yourself a little bit, your current role, and maybe say a little bit about your role within the community, particularly the U.S. community?

I’m Dan Katz. My current job is Chief Scientist at the National Center for Supercomputing Applications (NCSA), which is part of the University of Illinois Urbana-Champaign, USA. I also have research faculty positions there in the School of Computing and Data Science and in the School of Information Sciences.

Starting in 2012, I was a program officer at the National Science Foundation on a secondment, leading a program called Sustainable Software Infrastructure for Sustained Innovation (SI2). The intent of this program was to fund developing new software and to fund people that had developed software as part of a research project and wanted to make it available for other people to then use, and to make it more of a product and not just a research tool for themselves.

While I was doing that, it became really clear to me very quickly that no matter how much money I had, I couldn’t really support all the software that needed to be supported. That led me to think about what other things I could do that would encourage people to write software and share it, even if they weren’t being paid for it. That in turn led me to think about incentives and motivations and a bunch of different things, and it also connected me to the Software Sustainability Institute (SSI) in the UK that was also thinking about a lot of the same things.

Around this same time there was a Wellcome Trust workshop that I went to and a meeting that the SSI organized in 2013 or 2014, which led me to think about career paths as one of these issues, and research software engineering as a discipline is one of the things that came out of that.

I was thinking about it because in some sense, I’d gone through the same process myself. My PhD was in Computational Electromagnetics, and I worked on a software package that my advisor had written, and he maintained it when different grad students wrote additions to it. My PhD was on two theoretical methods that I implemented in this code, where we then used the code to test them to see if they worked. Over time I became more interested not just in electromagnetics that I was working on, but in different kinds of computational science and in data science as well.

I spent probably 8 or 10 years doing different kinds of software work and then after that, I ended up becoming a group supervisor and project manager. I stopped doing as much hands-on stuff, but I was still working with other people that were. So I think my interest was based on partly my experience, partly the experience of other people that I saw, and partly the fact that what I really wanted was to have better software, and a way to have better software was to have the people that write the software to have good careers so that they want to keep working on it.

The thing that ties these different pieces together for me is trying to have better research outcomes through better software. As the SSI says, “Better Software, Better Research.” That could be better career paths for people. It could be software citation, that helps those that work on software gain recognition for that software. It could be working with funders to encourage them to recognize the importance of software and have programs that support it – not just developing it, but also maintaining it. It could be looking at government policy in general or institutional policy and seeing how people get rewarded for doing this kind of work. The thing that they all have in common is that they’re intended to increase recognition of software, highlight its importance, and provide more rewards for people that actually work on it.

So you were thinking about research software engineering in 2013. At what point did you first hire someone to work as an RSE?

I was doing this when I wasn’t calling myself an RSE. When I was at the NASA Jet Propulsion Lab (JPL) as a group supervisor, in around 2000, I had a group that I would now call a group of eight RSEs. But we didn’t have that name then, so that wasn’t what it was.

When I left JPL in 2006 and went to Louisiana State University (LSU), I was the director for cyberinfrastructure development. We aimed to assess the computing, software, data storage, networking, and other resources needed for campus researchers to conduct better research and then determine how we could provide those resources. Part of that project included software, so there I had a group of five RSEs, who were in part institutionally funded. The ones at JPL were all project funded, as has been almost everything I’ve done since then too. LSU was the only place where there was an institutional commitment.

You’ve now had a few roles, many roles, and particularly leadership in this kind of area of research operation. What do you identify as yourself, and how has that changed through time?

I feel like I’ve become more general over time. Effectively I’ve gone from being a computational scientist in one particular field, to a computational scientist across a few different fields, kind of a data scientist as well, kind of a computer scientist, and an information scientist. Then from information science, I’ve become more interested in these human aspects.

Most of these progressions have begun with something very specific, and incrementally working towards generalising it. However, when focusing on general concepts, the specific tasks may not be directly addressed. So you have to think about who is handling the specific tasks, how do they work together, and whether there are shared practices that could help catalyse an organization that would help them.

Can you say something about your role in the U.S. RSE community?

After having come to the first couple of RSE conferences in 2016 and 2017, and some other interactions from prior to that, in 2018 I got involved in the International RSE survey (the first time that it was international as opposed to the U.K.) Simon Hettrick was looking for a couple of people in different countries to translate questions and answers into whatever was right locally. Sandra Gesing and I agreed to do that for the U.S.

I’d been thinking about the RSE idea and wondering if we could do something in the U.S. Therefore, Sandra and I added an extra question on the survey to identify volunteers interested in organising a U.S. RSE community. We gained ten initial volunteers from the survey. There’s a blog post on the U.S. RSE website that talks about its history and includes more detail.

Around the same time there was the first international leaders meeting that the U.K. association, which predated SocietyRSE, was hosting. They invited a number of people from the U.S. to attend. I had a conflict so was unable to attend, but there were five people from the U.S that went. Three of those five people had answered the survey, but the other two hadn’t. In total this gave us fourteen people, including Sandra and I, that were interested in the initial organising of USRSE.

We built an initial website, set up a Slack channel and did some initial things. We then sat around for about a year, where nothing progressed, because we just created these things and we didn’t publicise them and we weren’t really sure what to do.

I believe, but I won’t swear to it, that Ian Cosden sent a note towards the end of that year more or less saying “maybe we should actually do something now”. That started to move things forward, and I think is what led to a very informal steering committee that had nine people. It had a strong overlap with those original fourteen, perhaps a couple of others had joined around that time. 

That kind of group of nine of us then started doing things. Publicising, attending events, using social media and more. That gained us a strong initial group; we went from 10 people most of the first year to 50-100 at the end of that second year. There was interest and people seemed to want to do this, so we decided we should actually try to formalise things. We wrote a governance document, then had elections of those people and that’s what’s continued onward since then.

US-RSE’s steering committee has alternating two-year terms, with four people elected one year, five the next year, and vice versa. So we always have people that are continuous from one year to the other, with two-year terms. I was elected initially for two years, and then ran again for another two years. And then decided not to run again, as I though it was important that other people would start to provide new ideas and new leadership.

So while I don’t have an elected position now, there are still some things that I do. We’ve had a funders series talk that’s part of our outreach working group, and I lead six or seven people that take part in organizing it. Every six weeks, we invite a funder to discuss their work related to research software, with the goal of sharing insights about RSEs. Ideally, the funder is also interested in learning from us and understanding what we believe the funding agency should be doing differently. We went through about 10 funder talks, and then took a break during 2024, and are now discussing restarting this soon. I’m also part of the DEI and outreach working groups, and I do some work on the job posting team.

What would you say is your favorite thing about your own work in that community?

In some ways I miss being on the steering committee. We had meetings every two weeks and that regular insight into everything that was going on was fun in some ways.

The ability to have input into all these things as they were being discussed  was good,

rather than trying to talk about them after they’d already been born. So I definitely do miss that aspect.

I really feel like the funders series has been a good thing that other people probably could have done, but I don’t think anybody had really thought to do. Based on some of the other things that I’ve done, and other experiences and interactions that I’ve had, it was I think relatively easy for me to get people to start this because I was connected with many of them in some way.

In other organizations that I’ve been involved with where I’ve had something to do with the governance, I’ve often tried to create structures that guarantee that people that are on the steering committee can’t stay very long, so that there’s some kind of a turnover that’s kind of baked into the system. But so that we don’t lose the people that have been on the steering committee, in some organizations we’ve created an advisory committee that people rotate onto from the steering committee and continue as long as they want to stay there.

We haven’t done that with U.S. RSE, even though would have liked to, but we do have a steering committee alumni Slack channel. So we occasionally have some discussions there that happen. As an example, when Simon Hettrick initially asked me if I would be interested in talking about the US-RSE at RSECon, I asked the people on that alumni channel, which is the current steering committee as well as other people that had been, is anybody else was coming. If there was somebody that was on the current steering committee that wanted to do this, it would probably make more sense for them to do it than for me to. So we kind of have a channel to have some of those discussions, but I still kind of miss being involved in them more closely in some ways.

In your professional work, what would you say your favourite thing is?

It’s similar in some ways, the idea of finding problems that have solutions that are both technical and cultural. Where just building the technology by itself doesn’t actually solve the problem, you also need to worry about how the technology is going to get implemented.

An example of this is the software citation work, where over 18 months, myself, Arfon Smith and Kyle Niemeyer led this group that came up with the software citation principles. We then had these principles and we finished our group and I started another group, with Neil Chue Hong and Martin Fenner, to actually work on the implementation. We initially thought that this was going to be over a relatively short period too, but it turned out to be about seven years of work. We ended up thinking about all the different stakeholders and how we could assemble a representative set of different groups of the stakeholders. Then, how do we actually work with them, so that their policy or behavior changes over time.

The citation.cff format and tools that Stephan Druskat created was a piece of that, but having citation.cff by itself doesn’t actually solve a problem unless people are going to use it. So we had to work with Arfon to get that incorporated into GitHub. This was something that the overall group did, that I think actually made citation.cff popular, and will probably lead to it being a standard for citation in the future and something that people just do.

Today I see on Slack channels, among different communities, people talk about it without me saying anything, without somebody else saying “oh, I saw this, maybe this is what we should do”. Then every once in a while I see a GitHub issue that comes up where in a project somebody says

“We should create a citation.cff file” and they tag me on it and ask whether I have anything to say about this. I’m able to share the documentation and they can just go ahead and do it.

So it’s nice to see some of these things actually going forward, never as quickly as you would like, and at least not yet as fully as I would like, but it’s still good to see such progress.

What would you tell a new RSE, that wants to be the best RSE that they can be, to focus on?

One of the other things that I do is I’m on the Board of Governors of the IEEE Computer Society. The reason that I ran for that was to build connections between the Computer Society and the RSE movement. One of the things that we’ve done started when I was at a Board of Governors meeting that was at the Computer Society headquarters, and we had an evening reception to promote networking between staff and governors.

One person that I spoke to developed the career guides for the Computer Society. He asked whether I thought we could do a career guide about research software engineering. I told him it was a good idea, and this led to the current Research Software Engineers: Creating a Career Path—and a Career document that US-RSE and the Computer Society co-developed.

To do this, we outlined what it would look like and selected myself and three others to serve as sources of quotations, wth each of us providing different perspectives and insights for those interested in this position.

It was Rinku Gupta, who’s from Argonne National Lab, Caroline Jay from Manchester, Jeremy Cohen from Imperial, and myself. Each of us answered a set of questions, and then a professional writer assembled them into a nice glossy booklet and PDF.

A second key for RSEs is to focus on talking to researchers, regardless of whether or not you fully understand their work, to grasp their needs at a software level—what they aim to achieve, where software could help, and the challenges they face. While you don’t need in-depth knowledge of their discipline, you do need to understand it enough to identify the computational and software components.

I believe RSEs should practice engaging with people across different disciplines to identify common problems that could have technological solutions. The only way to achieve this is by having conversations with a wide range of people over time.

Gaining experience in discussing others’ work, as well as effectively communicating your own, helps uncover potential connections and align solutions with their needs.