Introduction

The sophistication and complexity of software required for today’s cutting-edge computational research is increasing at an unprecedented pace. Without high-level software engineering, problems can arise quickly in research code that limit its usability, sustainability, reproducibility, and even accuracy (Miller, 2006; Bhandari Neupane et al., 2019). Most domain researchers lack the time, experience, or incentives to consistently employ software engineering best practices; it is not uncommon for software tools and research code to become unusable after a project ends (Merali, 2010).

This has led to the emergence of the Research Software Engineer (RSE), a role that is relatively new to both Princeton and the broader research community, but is transforming the landscape of computational research across fields and disciplines. 

Many Princeton researchers have not had experience working with an RSE, and most RSEs hired today are the first to fill these key roles in research projects. This document defines the RSE role at Princeton, introduces the mission of Princeton’s RSE group, and provides guidelines for a successful partnership.

What is an RSE?

Coined in 2012, the term Research Software Engineer has been used as an inclusive title to describe trained software engineers who produce high-quality software for scientific research (Baxter et al., 2012). 

While their primary work is software development, the RSE often has intimate knowledge of a scholarly domain, as well as a deep understanding of the values, priorities and goals of academic research. An experienced RSE has both the tools and knowledge to collaborate closely with domain experts in a manner that ensures the quality, performance, reliability, and sustainability of the software needed to advance their research goals.

The RSEs make two other critical contributions to the research software ecosystem. First, they are mentors to novice software developers, including undergraduates, graduate students, and postdoctoral researchers, and elevate the full research team’s technical knowledge by exposing them to professional best practices. Second, RSEs serve as teachers, designing and teaching workshops and other training programs for the wider university community tailored to institution-specific audiences and needs. 

The RSE Group at Princeton

RSE Group Mission

The Princeton RSE group’s mission is to help researchers create the most efficient, scalable, and sustainable research codes possible to enable new scientific and scholarly advances.

We do this by working as an integral part of traditional academic research groups, providing leadership in the design and construction of complex and highly customized software systems. 

Our group is committed to creating a collaborative environment in which best software engineering practices are valued, and to sharing and applying cross-disciplinary computational techniques to new and emerging areas. We foster a culture of reproducibility, ensuring that our collaborative efforts contribute to the promotion and practice of transparent and replicable research methodologies.

RSE Group Leadership

The Research Software Engineering group is led by the Senior Director of Research Software Engineering, who reports to the Associate CIO for Research Computing. The group has two Associate Directors who contribute to the leadership and direction of the growing team.

RSE Partnerships & Funding

Funding for the RSE program is provided by Research Computing, the Provost, and the Dean for Research. Two partnership models are available within the RSE group: Co-Funding and Full Partner Funding. 

Co-Funding: These RSEs have a home department in Research Computing and report formally to one of the group’s Associate Directors or Lead RSEs. Each RSE is assigned to a partnering department, institute, initiative, center, consortium, or PI (referred to as "partner"). These partners agree to fund a portion (typically 50%) of the position for a finite term (typically 1–3 years) and Research Computing provides the remaining funding. Potential partners may submit short proposals for review by the RSE Steering Committee, which awards available RSE partnerships. Calls for such proposals occur as central co-funding is available. The RSE’s Annual Performance Review (APR) is completed by their direct supervisor (typically one of the group’s Associate Directors or a Lead RSE) with significant input from the partner. 

Full Partner Funding: These RSE positions are funded entirely by a partner. The partner commits to the RSE's participation in the RSE group with the same expectations as for other RSE members (including those who are co-funded). This includes meeting the expectations listed in the next section (RSE Expectations). The partner and RSE group leadership “co-supervise” the RSE. Although housing the RSE within Research Computing is encouraged, if the RSE’s home department is not Research Computing, then the RSE’s home department and reporting structure will be formally within the partner department/PI and the details of the co-supervision will be agreed upon at the time of hire. The partner covers all costs on items such as computer & peripherals, conference travel & fees, etc. The RSE’s APR will be completed by their home department supervisor with input from the co-supervisor. 

Regardless of funding method, the expectation is an open and collaborative evaluation between partners to ensure a successful engagement and as such, feedback from partners and all participating PI’s is regularly sought.

RSE Project Intake and Assignment

Allocating individual RSE time to specific projects can be managed in a manner best suited for all parties involved. Requirements tend to be unique, and therefore the structure of project intake and assignment should be organized in a way that addresses the needs of a partner organization while maximizing the ability of an individual RSE to make a meaningful impact. An established process for RSE project intake is important, especially when multiple parties are involved. RSE project intake typically falls into one of the following models:

PI project proposal & review

For department, center, or initiative partnerships, with many potential affiliated PIs, this is the most typical form of project intake and assignment. At regular intervals, an email request for software project proposals is sent to associated faculty in the partner department/center. Interested faculty respond with a short description of a potential project and a meeting with the RSE and RSE group leadership is scheduled. During the meeting, the goals and deliverables of the project, an estimated scope, and the expected time commitment are discussed while guidelines for productive collaboration are established. After spending time reviewing each proposal, the partner leadership (department chair/manager, etc.) meets with the RSE and RSE group leadership to select successful proposals and define the project commitment. The goal is to balance the strategic priorities of the partner and the feasibility of the project with the interests/skills of the individual RSE. This commitment is typically for a fraction of the RSE’s availability within a fixed project cycle (typically 6-9 months). Regular project check-ins are scheduled throughout the project cycle to ensure project goals are being met. Renewals and small maintenance projects are possible through subsequent calls for software project cycles. 

Single project partnership

When the partner is an individual PI or a single project, the RSE's sole focus is on the PI's lab or project. As such, there is no need for a process to request, review, and select new projects. Project check-ins and regular communication are still important to ensure project goals are being met. 

Ad-hoc projects

Occasionally, an RSE will take on a project by direct request or through a meeting. Together with the RSE group leadership and/or the partner representative, they manage the commitment and timeline. While this model advantageously allows for flexibility and autonomy of the RSE, maintaining this model increases difficulty with predicting workloads, which challenges the ability to advertise to potential PIs and can lead to an overwhelming amount of “walk-ins” and requests.

RSE Expectations

Regardless of funding, each member of the RSE group is expected to work on the research software projects as prioritized by the partner with an effort of roughly 85% of their time. The RSE group’s leadership team will support the RSE in ensuring that the priorities laid out by the partner are followed.

The remaining 15% of resource time is allocated to RSE group activities and professional development. The RSE, along with the RSE group leadership, will track efforts to ensure that the 15% target is met as closely as possible. Too much would take away from project work, while too little limits growth and minimizes the ability to leverage the collective RSE group knowledge.

These activities include but are not limited to:

• One-on-one meetings with their direct manager from the RSE group leadership team 
• Participation in all RSE group meetings. This includes:
  • One 90-minute RSE group meeting every other Wednesday.
  • One 60-minute Research Computing department meeting once a month.
• Occasional (2-4 times per year) participation in RSE group events, such as:
  • RSE project sprints - These short 1-3 day events provide a small team (2-4 RSEs) an opportunity to collaborate on a particularly challenging or technically edifying task. This leverages group expertise and provides one project the opportunity to benefit from others, as well as an opportunity for RSEs to learn new techniques and strategies. 
  • RSE code reviews - The best way to improve code quality is through code review, and one of the best ways to learn new programming approaches is to read other people’s code. RSE peers can take turns reviewing each other’s code for specific feedback and advice. Both the reviewer and reviewee benefit, as does the project whose code is the subject of the review. 
• Professional development. As largely independent professionals, RSEs must spend time and effort to maintain knowledge of advancing technologies. Research changes rapidly. Software development best practices change even faster. Learning is essential in these positions. Sometimes this is facilitated by participation in RSE group conversations. However, some other options should be explored regularly:
  • Attending training, tutorials, and conferences. 
  • Contributing to open-source projects and other project-based learning opportunities.
  • Collaborating on other Princeton RSE group member projects.
• Deliver Training (optional)
  • As mentioned in the RSE overview, RSEs know software engineering best practices that are extremely useful to share with researchers. One of the most impactful approaches to sharing such information is through tutorials and workshops. PICSciE oversees several such events. When interested, RSEs are encouraged to deliver workshops and mini-courses to share their knowledge with the broader community. 

In some cases, RSEs are asked to track their time. This is done on a case-by-case basis, depending on the specific situation of each RSE. RSEs who are supporting more than one initiative typically track their time to ensure that each project is getting an appropriate effort.

RSEs are typically classified in the University as Exempt AIT professionals with a 36.25-hour work week (7.25-hour work day). They accrue 2 vacation days each month. RSEs are committed professionals who are dedicated to their projects’ success. RSEs are expected to be independent and capable of managing their own time and efforts. That being said, awareness of an RSE’s expected weekly effort by the partner and the RSE group leadership will contribute to continued success, and as such, performance evaluations are based on impact and production rather than timekeeping.

RSE Partner Expectations

As outlined above, RSE partnerships are flexible and can be managed in a manner best suited for the partner. Partnerships focused on a single project should rightfully be managed differently than a departmental partnership targeting multiple projects led by multiple PIs.

A primary goal of the RSE group is to develop a cohort of RSE professionals who are committed to both the success of research projects and the intellectual growth of the RSE group. A strong connection with their RSE peers will ensure that best practices are shared. RSEs are actively encouraged to have physical office space in Research Computing (RC) buildings (to be near other RSE and RC professionals) as well as in the partner’s space. In some cases, this can be difficult, or may not be possible. The recommendation is for 50-80% of an RSE’s time to be spent in the partner’s space nearest the research groups, while the remaining time would be spent in RC spaces near the other RSEs and RC professionals. 

To produce high-quality, sustainable software, clear communication and a joint understanding of the target lifecycle are crucial. 

To ensure the long-term success of a project, it is necessary to have regular communication about the pace of development and prioritization between the partner, the RSE, and the RSE group leadership.

The focus on quality and best practices requires careful balance with research and scholarly output timelines to limit the pressure to speed up development. From a software engineering perspective, building robust software will always take longer than the development of the initial functional proof-of-concept. One of the hallmarks of an experienced RSE is their understanding of both research publication incentives and research software requirements. The RSE balances anticipated project scope and research deadlines to produce software that not only meets short-term research needs but is sustainable, maintainable, and extensible. Projects are most successful when timelines and project scope are developed collaboratively and refined continuously to optimally balance priorities. Several best practices may initially slow down the addition of “new knowledge” or features but facilitate the development of new aspects of a project while ensuring correctness, reproducibility, and the long-term success of the project. 

We strongly encourage communication between partners and both the individual RSEs and the RSE group leadership in the case of questions about the pace of development or the prioritization of effort. 

The demand for experienced RSEs continues to grow exponentially, placing Princeton in a challenging position of having to compete with a market that values research experience, mathematical and statistical software development, and experience with software engineering best practices at a salary structure we cannot always match. To retain our excellent RSEs, we want to ensure our work environment is as positive and rewarding as possible. Enabling intellectual challenges, providing work-life balance, and promoting valued collaboration are all aspects of working at Princeton that keep us competitive. Together, we need to prioritize the achievement of these benefits to increase job satisfaction and retain our talented RSEs.

RC, PICSciE, and each RSE partner need to work together to create a positive and rewarding work environment for the RSEs, or we will risk losing highly talented RSEs. 

Communication between all parties involved in the partnership is critical. If expectations are not being met, then it behooves everyone to quickly address the problem to collaboratively work towards a solution. 

Publications & Authorship

RSEs sit at the intersection of scholarly research and software development. A common and extremely important output of scholarly research is the journal/conference publication. RSEs, by design, are not directly measured or advanced  based on their publication output. Even so, many RSEs (especially those from a pure research background) still value such publications.

We encourage RSEs, PIs, and/or partner managers to discuss authorship as soon as possible. It is typically recommended that if a publication would not have been possible without the RSE, then the RSE should be included as a co-author. 

RSEs will occasionally be interested in publishing their work in a manner appropriate for the field and individual. Please refer to the separate document on RSE publishing guidelines for details about how the RSE group handles potential RSE publications.