Nordic-RSE

International RSE Day 2026!

2026-10-08T00:00:00+00:00

Every year, the second Thursday of October is International RSE Day!

Today, we celebrate our work and contributions to research, and we share widely our passion for our job. Many in the Nordics and all over the world are celebrating in different ways, from the RSE community in Helsinki meeting for a community lunch, to blog posts, to simple hashtags. Some of us are celebrating simply by enjoying a good cup of coffee together in our weekly coffee break</a> taking place every Thursday at 09:00 CE(S)T / 10:00 EE(S)T: everybody is welcome!

Here is to us! Happy International RSE Day!

Nordic RSEs: satisfied, skilled and in demand but looking for clearer career paths

2026-07-30T00:00:00+00:00

Insights from the International RSE Survey 2026</h2>
This post shows results from the 5th international RSE survey that ran in early 2026. Over 950 Research Software Engineers from 55 countries shared insights into their career and interests. 
The full dataset is available for download at https://github.com/softwaresaved/RSE_survey_longitudinal/</a>. An interactive dashboard with all international RSE survey data is available at https://rse-survey.soton.ac.uk/superset/dashboard/RSE_survey/</a>. We have also compiled a Quarto book where you can review the findings for each survey question: https://nordic-rse.org/rse-survey-2026/</a>.
The analysis below is based on 62 submitted responses from the Nordic countries. Percentages are calculated from the respondents who answered each question, so the number of responses may vary slightly between questions.
Most submitted responses came from Finland (32.3%), Sweden (30.6%), and Norway (16.1%), followed by Estonia (12.9%), Denmark (6.5%), and Iceland (1.6%).
The sample spans early-career and mid-career respondents. The most common age groups were 35 to 44 years (44.3%) and 25 to 34 years (32.8%), followed by 45 to 54 years (18.0%). In the analysis below, we use three age groups: under 35, 35-45, and 45+.

Interdisciplinary RSE community: Broad but concentrated in STEM</h2>
Nordic RSEs work across many disciplines, but the survey responses are strongly concentrated in STEM fields.
Computer Science was the most common work area, selected by 71.0% of respondents. This was followed by Biological Sciences (37.1%), Physical Sciences (32.3%), and Medicine/Health Sciences (27.4%).
Computer Science was also the most common disciplinary background, selected by 38.7%. Physical Sciences followed at 22.6%, Biological Sciences at 9.7%, and Mathematical Sciences at 8.1%. 
Most respondents had advanced academic qualifications: 54.8% held a PhD and 40.3% held a Master's degree. 

Key finding: The Nordic RSE community is strongly rooted in computing, but RSE work supports many scientific domains. However, survey responses are strongly concentrated in STEM while social sciences appear underrepresented. </div>
RSE role and software experience</h2>
Software development is central to the work of most respondents. 93.5% write software for academic research as part of their job, and 67.2% consider themselves professional software developers.
Many also have substantial experience: 35.5% reported 15+ years of software development experience, followed by 10 years (17.7%) and 5 years (11.3%).
Most respondents are not primarily in leadership roles. Only 8.2% said that most of their role consists of leading a group of software developers or RSEs.
The software they develop is often used beyond an individual researcher. 75.9% reported writing software for more than two users.
Employment and job titles</h2>
Most respondents reported relatively stable employment conditions. 74.2% were in permanent employment, 22.6% were on fixed-term contracts, and 95.2% worked full time. 
Among respondents under 35, permanent and fixed-term positions were more evenly balanced: 55.0% permanent and 45.0% fixed-term. This may reflect the fact that many younger respondents are in PhD or postdoctoral positions, which are usually fixed-term.
Job titles varied widely. Respondents reported their job titles in free text, which we grouped into broader categories. The most common was Software Engineer or Developer (37.5%), followed by Researcher (17.5%), Technical/Professional Support Role (12.5%), and Faculty/Professor (7.5%).
In addition, 30.9% said they are known within their group by a different job title than their official one. This highlights that RSE work is often present even when the formal title does not say "Research Software Engineer".
Most respondents work in universities (79.0%). Universities were also the most common background for respondents' previous role (51.6%), followed by private companies (22.6%).

Key finding: Most respondents are in permanent, full-time employment, but fixed-term contracts are more common among younger respondents. RSE work also appears under different job titles. </div>
Time allocation: protecting time for software and research</h2>
Software development took the largest share of working time, at 44.7% on average. This was followed by research (19.9%), other activities (15.6%), teaching (14.9%), and management (14.4%).
When asked how they would prefer to spend their time, respondents wanted more time for software development and research, and less time for management and other activities. The largest desired reduction was in management time, at -6.6 percentage points.
There were some differences by age group. Respondents aged 35-45 and 45+ wanted to reduce teaching time slightly, while respondents under 35 wanted to increase it. This may reflect differences in career stage and responsibilities.
Overall, the results suggest that RSEs see software development and research contribution as the core of their work, while management and other organisational tasks can reduce time available for these activities.

Key finding: RSEs spend most of their time developing software and would like even more time for software development and research, with less time spent on management. </div>
Technical toolbox: Python, GitHub, HPC and collaboration</h2>
Python is by far the most commonly used programming language among respondents, selected by 95.1%.
Git was reported as a version control tool by all respondents, and GitHub was selected by 93.4% as a collaboration platform for software development. Other frequently selected collaboration tools included Git (70.5%), GitLab (52.5%), and Slack (50.8%).
HPC was the most frequently selected deployment environment, at 58.6%. This was followed by laptops or desktops (48.3%), stand-alone servers (39.7%), and cloud platforms and GPU (31.0%). 
For day-to-day development, 73.3% primarily use GNU/Linux, followed by macOS (15.0%) and Windows (10.0%).
There are also some age-group differences in programming language selections. Among respondents aged 45+, the most frequently selected languages after Python were JavaScript at 42.9%, C++ at 28.6%, and SQL at 28.6%. Among those aged 35-45, R was selected by 48.1%, JavaScript by 44.4%, and SQL by 37%. Among respondents under 35, JavaScript was selected by 30%, while C++ and Rust were each selected by 25%. 

Key finding: Python, Git, GitHub and HPC are central parts of the Nordic RSE technical toolbox. </div>
Generative AI in RSE work</h2>
Generative AI tools are already used regularly by many respondents. 42.6% reported daily use in RSE-related tasks, and 19.7% reported weekly use. 16.4% reported never using generative AI in their RSE work.
The most common use case was writing and debugging code, selected by 82.0%. Designing software architecture was the least common use case, at 20.0%. This suggests that generative AI is currently used more for practical coding tasks than for higher-level software design.
Among tools used at work, ChatGPT was selected by 63.3%, followed by Claude (40.8%) and Gemini (26.5%). 
Looking ahead, 59.3% expected generative AI not to significantly change demand for RSE roles over the next five years. 22.2% expected demand to increase, while 18.5% expected it to decrease.
Most respondents expected generative AI to increase their own productivity (66.1%). Views on code quality and job satisfaction were more mixed. 44.6% expected code quality to stay the same, while 36.8% expected job satisfaction to decrease. 
When asked what skills are needed to use generative AI effectively, common themes included critical thinking, scepticism and output validation; solid software engineering skills; prompt engineering and generative AI literacy; judgment about when and how to use AI; code comprehension; and testing and quality assurance.

Key finding: Generative AI is widely used for writing and debugging code, but software architecture is the least common use case. </div>
Software quality, testing and software citation</h2>
Developer testing was the most common testing approach: 78.7% selected "developers do their own testing". Automated testing with continuous integration was selected by 52.5%, while 31.1% selected "no formal testing but user feedback".
Software citation appears to be common among those who answered the citation questions. 82.1% said they always reference software directly and 66.7% said they always reference a published paper describing the software. 
Persistent identifiers are less common. 80% of respondents who answered this question said they never generate a DOI or other persistent identifier for their software.
Open-science practices appear widespread: 88.7% reported having an ORCID ID, and 94.9% of those who answered the licensing question said they always license their software with an open-source licence.

Key finding: Testing and software citation are common among respondents, but generating persistent identifiers such as DOIs is less common. </div>
Job satisfaction and labour market demand</h2>
Respondents reported high levels of satisfaction. 87.1% were satisfied with their current job position, while 4.8% were unsatisfied. Career satisfaction was also high: 80.3% were satisfied and 9.8% were unsatisfied.
Many respondents also saw their expertise as relevant beyond their current workplace. 69.0% agreed that their experience is in demand on the labour market, compared with 15.5% who disagreed. This confidence appears across age groups, and is especially strong among respondents aged 45+, where 83.3% agreed that their experience is in demand. Among those under 35, 73.7% agreed, and among those aged 35-45, 57.7% agreed while 19.2% disagreed.
Recognition of research contribution was stronger from supervisors than from institutions. 81.4% agreed that their contribution is recognised by their supervisor, compared with 61.0% who agreed that it is recognised by their institution. 

Key finding: Most respondents are satisfied with their jobs and careers, and many feel their experience is in demand. Recognition from supervisors is reported more strongly than recognition from institutions. </div>
Career progression and promotion uncertainty</h2>
Although many respondents are satisfied and feel that their skills are in demand, career progression within current roles appears less clear.
Overall, 48.3% disagreed that they are likely to gain a promotion within their current group, while 20.7% agreed. The pattern was stronger among older respondents: among those aged 45+, 58.3% disagreed and only 8.3% agreed.
Promotion processes also appear unclear. 51.8% disagreed that the process for gaining a promotion is clear and understandable, compared with 28.6% who agreed.
Younger respondents were generally more positive about career opportunities. Among those under 35, 60.0% agreed that there are many opportunities within their chosen career plan. Among respondents aged 45+, 72.7% disagreed.
This age pattern should be interpreted carefully. For younger respondents, especially those in PhD positions, the next career step may be more clearly defined. For mid-career and senior RSEs, progression may be less standardised, especially where institutions do not have formal RSE career paths.
At the same time, 43.9% agreed that their next position is likely to be an RSE or Research Software Developer role. This suggests that many still see themselves continuing in the field, even when promotion routes are unclear.

Key finding: Promotion routes are often unclear, especially beyond early-career stages. </div>
Skills development and training needs</h2>
Most respondents learned the skills they need for RSE work through practice. 83.6% selected learning on the job, and 65.6% selected self-taught learning. A university course or module was selected by 50.8%, and online courses by 32.8%. 
The most common future skill interests were AI-assisted development and agents" (22.5%), HPC, parallel and GPU computing (22.5%), communication, teaching and writing (20.0%), DevOps, CI/CD and pipelines (12.5%), and software testing, quality assirance and verification (12.5%).
Many respondents are also involved in teaching or training. 47.5% reported providing training one to two times per year, and 50.9% teach or support credit-bearing modules or courses.
Time for personal skills development varies. 38.3% said they always have some time for their own skills development, while 28.3% said they have time only in weeks with a low workload.

Key finding: Most RSEs learned their skills through practice and self-study. Future skills interests include AI-assisted development, HPC, DevOps, testing and communication. </div>
Networks, community and local support structures</h2>
Many respondents have peer networks beyond their closest colleagues. 62.0% reported having such a network, including 24.1% who had to build it from scratch.
A majority, 55.9%, reported being part of a dedicated research software group within their organisation. This suggests that Nordic RSEs already have local structures for support and collaboration. 
44.1% are members of an RSE association. Among respondents who answered the follow-up question about interest in joining an RSE organisation, 78.6% said they would be interested.
The main things respondents hoped to get from such an organisation were networking (85.1%), research software standards (72.3%), training (57.4%), and research collaborations (53.2%). Priorities varied by age: respondents under 35 emphasised job opportunities (66.7%), while those aged 45+ placed more weight on research collaborations (63.6%).
Funding sources show a mix of institutional and project-based support. Institutional support was selected by 72.9% and grants by 67.8%. Access to dedicated RSE funding appears limited: only 16.7% said they have access to RSE-type grants in their institution or country, while 40.0% said no and 43.3% did not know. 

Key finding: Many RSEs have peer networks and local research software groups, but broader community structures could help with networking, standards, training, and collaboration. </div>
Publications, dissemination and conferences</h2>
51.6% of respondents have published a paper about their software, for example in journals such as JOSS or SoftwareX. 
When software contributes to a paper, acknowledgement practices vary. Being named as a co-author is relatively common: 25.8% said this always happens and 54.8% said it happens sometimes. Being named as main author is much less common: 2.9% said this always happens, while 64.7% said it never happens.
47.4% have presented software work at a conference or workshop. Commonly mentioned areas included digital humanities, HPC and e-infrastructure, chemistry and materials science, astronomy and physics, and RSE community conferences.

Key finding: Many Nordic RSEs publish and present their software, but authorship and acknowledgement practices vary. </div>
Project workload and resilience</h2>
RSE workloads often include several projects. 80.3% of respondents are currently involved in one to four software projects, and 39.7% work on projects that typically include a project manager.
Project resilience appears to be a concern. 58.9% said their current project would stall if just one knowledgeable developer left. Only, 16.9% work on projects that typically have a plan for how to cope with developers leaving.

Key finding: Many projects depend on a small number of knowledgeable developers, and relatively few have succession or departure plans in place. </div>
What respondents want from a potential future Nordic-RSE institute</h2>
Respondents were also asked how a potential future Nordic-RSE institute could support community engagement and knowledge transfer. The most common answer was organising conferences, workshops, and similar events, selected by 86.7%. 
When asked what tasks a Nordic-RSE institute should take on, respondents most often selected advocacy for research software towards politicians and decision makers (71.7%), community engagement and training (70.0%), and promotion of RSE career paths (70.0%).
These priorities fit well with the broader survey findings. Respondents are skilled, often satisfied, and feel that their expertise is in demand. At the same time, they want clearer career structures and more opportunities to learn, connect, and be represented.

Key finding: Respondents see a Nordic-RSE institute mainly as a platform for events, advocacy, career development, and community training. </div>
Please share your thoughts or comments!</h2>
We would love to hear what you think. Please take a moment and share your thoughts about the survey and the analysis in our collaborative document: https://hackmd.io/@nordic-rse/rse-survey-2026</a>.
What's next</h2>
These findings will directly shape how we, together with you at Nordic-RSE develop our activities and priorities going forward. We'll follow up with a separate post on the concrete steps we're taking in response. We will also link to resources on where to find training, networking and career that already exist for RSEs in the Nordics today. If you would like to get involved, come to one of our coffee breaks or biweekly meetings: https://nordic-rse.org/join/</a>

The Finnish RSE meetup 2026

2026-03-16T00:00:00+00:00

The Finnish RSE community held its second national meetup at the Nordic Basic Scientific Computing Days, this time side‑by‑side with the Scientific Computing team gathering, creating a combined space where research software and scientific computing communities could meet. With 30 participants from 7 organizations, the room quickly filled with the kind of energy that only happens when people who “get each other’s work” finally meet face to face.
The program combined structure and spontaneity: one inspiring keynote, four contributed talks highlighting the different kind of RSE work across Finland, as well as a discussion and a laptop session. But as always, the most important part of the day wasn’t on the formal agenda, it was the networking, the hallway chats, the new connections, and the sense of community taking shape.
The program included a mix of keynotes, technical talks, and open discussion that revealed just how diverse and community‑minded Finnish RSE work already is:
Kamyar Hasanzadeh explored the many ways GIS tools can be shared, e.g. scripts, notebooks, plugins, web apps, and why each comes with trade-offs. The core message: sharing isn’t just a technical choice but an audience question. Different user groups require different solutions, and no single format works for everyone. Sustainable sharing means balancing reproducibility, usability, and maintenance while being clear about who the tool is really for.
Ina Pöhner and Rafael Lopes Almeida shared the story of TargetCAT, a small workflow script that grew into an essential tool for data‑driven drug design. Their talk highlighted the hidden labor of researcher‑developers: fragile manual workflows, invisible coding work done outside official hours, and tools that expand faster than they can be maintained. The reboot of TargetCAT—supported by industry collaboration and CodeRefinery—showed how proper RSE practices can turn a “Frankenstein” script into sustainable software.
Jeremy Cohen from the Imperial College London opened the day with a keynote full of practical lessons from the UK RSE movement: how grassroots communities can grow, how volunteer energy can be nurtured, and why visibility, mailing lists, and lightweight opportunities to contribute matter so much. He also connected the local discussion to global efforts such as the Society of Research Software Engineering, the Research Software Alliance, and initiatives like DORA and the Hidden REF that push for research software to be recognized as scholarship.
Julia Niskanen introduced a toolchain for making proprietary Origin .opju files FAIR‑er, using Python to extract data into open formats—highlighting both the pains of closed ecosystems and the motivation to publish tools that help others avoid the same problems.
Frankie Robertson’s talk on SymPy and computer algebra systems introduced symbolic workflows and the joy (and occasional chaos) of mixing scientific Python with more traditional CAS tools.
Discussions throughout the day circled back to a few recurring themes:

Community spaces matter, whether that’s our Nordic-RSE Zulip chat or regional meetups, it helps by meeting people to have someone to ask/discuss; especially when you're the only RSE in your department.</li>
RSE visibility needs to increase, especially toward funders, universities, and policy makers. People called for clearer career paths, KPIs that reflect real contributions, and national‑level coordination.</li>
Training and shared knowledge are key; everything from LLM-assisted coding to infrastructure best practices to guidance for newcomers on unions and support networks.</li> </ul>
Based on these discussions, we will continue to consider how the existing Nordic-RSE association or maybe also a new Nordic or Finnish RSE organization may help people feel less alone, more supported, and more connected.
We are deeply grateful for the support we have received for this event: This meetup wouldn’t have been possible without the support of Aalto Scientific Computing, the Software Sustainability Institute, the Society of Research Software Engineering, and a handful of dedicated individuals who care about building a strong RSE network in Finland. Everyones contributions helped create a welcoming space where RSEs could share, learn, and feel seen. 
Thank you!

Nordic-RSE friendship book

2025-11-17T00:00:00+00:00

At the Nordic-RSE conference 2025 we asked participants to fill out a Nordic-RSE friendship book page. About 20 people submitted their page to create this overview of the community, including their wishes and greatest achievements. This is a summary of what they wrote:
A variety of job titles, preferred languages and career stages</h3>
RSE enthusiasts may "hide" behind any of the following job titles: 

(Digital) Research (Software) Engineer</li>
System administrator</li>
Data Engineer / Scientist</li>
HPC Engineer</li>
Researcher</li>
XX Specialist / Expert.</li> </ul>
They often like to code in Python, but you may also find them using R, C, Julia, HTML/JavaScript, JS, Rust, STAN, Mojo, Bash, Groovy, Haskell, Fortran, C++, and OCaml or "whatever gets the job done". 
Here are some highlights of peoples git commit message of their current career stage: 

linting (no changes)</li>
detached career HEAD state</li>
taking a break soon – working on two ‘branches’ created with another developer.</li>
small update waiting for big PR</li>
"Eierlegende Wollmilchsau" (the legendary egg-laying wool-milk pig)</li>
WIP</li>
stable now, will have to be revised</li>
empty message, commit aborted</li> </ul>
Codes written to power research vs simplifying everyday tasks</h3>
People described a wide range of “most useful” code they’ve written, spanning both highly technical tools and small personal utilities. These include scripts for analysing behavioural data, generating scientific colormaps, visualising audio signals, calculating twilight times, and supporting DNA nanotechnology platforms. Others built practical automation—aliases for common commands, data-transformation pipelines, hyperparameter search routines, and plotting tools for complex statistical outputs. Some created large-scale research software, such as pharmacokinetic simulators, protein-modelling toolkits, molecular-dynamics workflows, and systems for running PyTorch on supercomputers. A few mentioned niche or personal favourites, from RPN calculators and regulatory-genesis analysis tools to code that plays YouTube channels or helps explore electrons and atoms — all illustrating how useful can mean anything from powering major research to simplifying everyday tasks.
RSE Olympics would be fun!</h3>
The “RSE Olympics” span a wonderfully chaotic mix of technical prowess and creative problem-solving: from assembly-level speed contests and mastering system architecture, deployment, HPC, SLURM, and AI workflows, to niche events like Python packaging, installing stubborn R packages, and “ansiblifying all the things.” Competitors show off MacGyver-style hacks using libraries never meant for their purpose, tackle research data management and data-standardisation marathons, and craft web-based research tools. Judging panels evaluate feats of linting, unit-test-adding, and code-review-starting, while side events include ranting about overpriced spaghetti-code software and fencing with rogue computing parts. The suggested disciplines celebrate the full spectrum of RSE ingenuity.
Give resources to RSEs and you will get...</h3>
With infinite resources, people would pour them into ambitious scientific infrastructure, transformative education, and cleaner, more sustainable research software. Their dreams range from advancing lattice field theory, quantum codes, molecular modelling, drug-design tools, and massive ML-HPC training systems to building a better operating system for science itself. Many would fund universal training: Intro to Git and Python/R courses at every university, comprehensive learning materials, and dedicated programs to teach researchers reproducible workflows. Others imagine perfect research data and metadata management, refactoring critical scientific software, or creating world-class environments such as a fully supported supercomputer-ready R ecosystem. Some would invest in visualisation frameworks, sustainability in programming, genealogy knowledge systems, or even verified safe AI. And of course, with limitless resources, there’d still be room for joyful explorations like large wisdom productions and microbenchmarking.
Training needs and community wishes</h3>
People expressed a need for training that strengthens both their technical depth and their ability to work effectively across diverse research and software-engineering environments. High on the list were practical skills—containers on HPC, SLURM, orchestration, IT security, managing Pis, and functional programming—along with language-bridging courses such as R for Python users and Python for non-Python users. Many want deeper computer-science foundations, including software design, design patterns, and understanding which core CS concepts matter in RSE work. Others highlighted training in workflow sustainability, ricing, HTML presentations, and handling AI responsibly in coding and teaching. There’s also demand for domain-specific expertise (like language technology), support for acquiring real depth in existing skills, and even meta-skills such as TTT (train-the-trainer) and guidance on how to turn RSE work into a stable full-time career.
People hope that Nordic-RSE will offer a blend of community support, practical resources, and structural recognition for RSE work. Wishes include seminar series, explainers of day-to-day tasks, and more technical training tailored specifically to RSEs, alongside non-academic skills development and accessible slides from events. Many want better funding—both long-term and for attending conferences—as well as SIGs, code-review groups, and institutional pressure to take software quality seriously. Others imagine lighter touches: improved coffee-break timings (or afternoon alternatives), cookies, a “punscherulle,” and social events like future meetups. Finally, members would welcome shared infrastructure such as cloud programming services, all aimed at strengthening the RSE community and making their work more visible and supported.
Why join Nordic-RSE?</h3>
Based on participants answers on the question what Nordic-RSE is to them, Nordic-RSE is a welcoming, community-driven initiative that brings together like-minded people interested in research software engineering. It provides a great forum to share experiences, foster collaborations, discuss technical details, and gain inspiration. Members value it as an exciting, inclusive, and growing community that supports knowledge exchange, networking, and professional development, often highlighted by its annual conference.
Thank you to everyone who participated, it was fun creating the pages and reading your answers! Maybe next year we will do this again and use it during the conference.

RSE worldwide session at RSECon25 - taking inspiration back to the Nordics

2025-10-23T00:00:00+00:00

In September 2025 I visited the RSECon 2025, the RSE conference in the UK with my colleague Ruslan Zhuravchak as representatives from the Nordics. We had earlier been invited by Claire Wyatt, the leader of the RSE worldwide session to present about Nordic-RSE. 
So we undusted our old Nordic-RSE presentation and went to work. What have we been up to in the last year (since the last RSE worldwide session)? And what a joy it was to look back at our achievements!
Greetings from the North
We had a successful in-person conference in Gothenburg this year with 43 participants, 23 contributions and a lot of networking. Read more about it in our conference blog post</a>. 
Some members of the community worked on getting the Journal of Open Source Software acknowledged and ranked in the Finnish Publication Forum. This makes it possible for PhD students to include a software paper into their PhD. Read more about that accomplishment in our news post</a>. 
Of course, we also have our challenges and shared about them in order to spark the discussion with other associations. 
Our main challenges these days is to come up with some membership benefits, retaining momentum and grow the group that "does stuff". 
We concluded with our next steps: Our next Nordic-RSE conference will take place in June 2026 in Tromsø, Norway. Apart from that we had a lunch meetup of RSEs in the capital region of Finland to celebrate international RSE day. And in February 2026 we will gather Finnish RSEs and friends as well as other people working around and supporting researchers (data stewards, infrastructure support etc.) in Espoo for No-BS Computing (Nordic Basic Scientific Computing) meetup. 
We are also taking up or continuing our involvement with the international RSE council, survey and conference committee. 
Presentation slides: https://doi.org/10.5281/zenodo.17381047</a>
But now, what have we learned from other presentations in the RSE worldwide sessions?
Shared challenges, inspiring solutions
It was inspiring to see how active and diverse the global RSE community has become - from volunteer-led networks to nationally funded organizations. Despite the differences, we all seem to face similar challenges: keeping the community alive over time, getting proper recognition for RSE work, finding sustainable funding, and reaching new people. It was comforting (and motivating!) to realize that we’re not alone in this.
Many groups shared creative ways to tackle these issues. In France, RSE roles are formally recognized through the REFERENS job framework - a great step towards visibility. The Dutch community runs mentoring and onboarding programs to help new RSEs grow. In Canada, the Digital Research Alliance connects RSE work directly with national research infrastructure. And I loved the grassroots energy from RSE Asia and RSE Chile, showing how much can be achieved through passion and persistence.
The Society of RSE in the UK continues to impress with its scale and impact — 400 participants at their annual conference and multiple ways to engage, from mentoring to grants and surveys.
Taking inspiration back home
We came back from RSECon'25 full of ideas and motivation. For Nordic-RSE, we’ll start or keep exploring how to make RSE roles and work more visible, look into the necessity of supporting local and national subcommunities, and how to secure stable support for our activities.
Thanks to the Software Sustainability Institute for funding my visit to RSECon this year via my fellowship on community building within Finland and the Nordics. It enabled a lot of new connections and deepened existing ones, as well as learning from the more experienced community builders and associations and of course all the great talks! 

RSE Meetup in the Helsinki Region – Celebrating International RSE Day!

2025-10-21T00:00:00+00:00

On International RSE Day, October 9th 2025, a group of 15 research software engineers and enthusiasts met up for lunch in the Helsinki region. It was great to connect in person, to get to know each other, share common challenges, and explore ideas for future collaboration.
This was the start of a local network of RSEs and RSE-friendly folks in the capital area — and we hope it’s just the beginning! Silent enjoyer or an active co-creator, everyone is warmly invited to join Nordic-RSE and be part of our growing community. 
What’s Next?</h3>
We’ve got some exciting events coming up:
Nordic Basic Scientific Computing (No-BS Computing) February 2–4, 2026 in Otaniemi, Finland -> A meetup for people who support academic research through computing and data expertise.
“This isn’t a time to advertise how great our tools and services are. It’s a time to look under the hood and talk about all the problems we encountered on the way (and the problems we expect in the future) so we can get better.” The first day will feature a Finnish & Friends RSE meetup. Program wishes are welcome — registration opens soon!
Nordic-RSE Conference 2026 June 9–10, 2026 in Tromsø, Norway Our main community event with sessions on tools, workflows, running RSE teams, and funding models. Submissions and registration will open early 2026, and you can even join the organizing team!
A huge thanks to the Software Sustainability Institute for sponsoring our lunch meetup and helping us celebrate the global RSE community!

JOSS re-evaluated as JUFO 1 in Finland, expands its definition

2025-05-28T00:00:00+00:00

The Finnish Publication Forum</a> (JUFO) has re-evaluated the Journal of Open Source Software</a> (JOSS) as level 1, making it easier fo researchers to get credit for their software contributions within the Finnish academic system. Among other things, the re-evaluation will make it easier for Finnish PhD students to include JOSS publications in article-based dissertations.
The re-evaluation followed a modification of JUFO level 1, adding the criteria to include data and methods supporting research results. This change paves the way for further recognition of scientific work beyond, and in addition to, traditional scientific publications.
JUFO levels are important within the Finnish academic system. The Finnish Publication forum (Finnish: Julkaisufoorumi; JUFO) ranks publication channels on a 0-3 level, with 1 indicating basic level channels up to and 3 which is reserved for the most selective channels. JOSS's previous ranking of 0 indicated publication channels that are not considered to meet basic criteria such as primarily publishing scientific output and having a proper editorial and peer-review process. Since 2015, the classification has been used to measure the research output of universities, and around 14% of all of Finland's universities' basic funding is based on the number of publications during the year, and their JUFO level. Naturally, this means that the value of publications in Finland is inevitably linked with their JUFO level.
The Journal of Open Source Software (JOSS) is a diamond open-access software journal. Software package authors can submit short articles describing their software. The journal uses an open peer-review process which focusses on also improving the quality of the software itself such as ensuring it has adequate automated testing and documentation, and that it behaves as described.
Members of Nordic-RSE helped to escalate the issue, although the process was not always easy, with proposals to re-evaluate the journal from those involved with Nordic-RSE dating back to at least 2020. "Persistence and open, apologetic debate with the Publication Forum was a key part of the process" says Frankie Robertson, currently at the University of Jyväskylä. Through the continued efforts of Luca Ferranti, currently at Aalto University, the issue was brought up multiple times, and eventually escalated to a steering group meeting, resulting in a decision to modify the definition of JUFO 1 in the handbook given to JUFO's evaluation panels to include publication channels which include data and methods (Finnish: menetelmät ja aineistot) supporting research results, in addition to research results themselves. (The relevant meeting minutes are available (in Finnish) here.</a>)
The change helps to bring JUFO guidelines in line with recommendations made by the Finnish National Board on Research Integrity (TENK). In particular, the policy for open research data and methods</a>, where principle 3 states that, "The researcher's merits in the promotion of good data management, work related to research data and methods, and the appropriate opening of research data and methods are valued and can support the researcher’s career".

Nordic-RSE conference 2025: Thank you for a great time!

2025-05-27T00:00:00+00:00

Nordic-RSE 2025: That’s a Wrap!</h1>
The second Nordic-RSE in-person conference took place on May 20-21 2025 in Gothenburg, Sweden. The conference was made possible thanks to the support of the Gothenburg Research Institute in Digital Humanities</a> and the Software Sustainability Institute</a>, and it was for anyone passionate about research software engineering (RSE) - whether by writing research tools, supporting scientific software, or just being curious about the field. We built this event to be a space where people can learn, connect, and share knowledge. 
And that’s exactly what happened in Gothenburg this May!
A Look at the Numbers</h2>
This year, we welcomed 45 participants to the Humanisten building at University of Gothenburg over two full days. We had a packed program, with:

1 keynote talk</li>
14 talks</li>
3 discussion sessions</li>
2 tutorials</li>
4 posters</li> </ul> What We Talked About</h2>
The range of topics was wide and reflected the diversity of interests within the Research (Software) Engineering enthusiasts community in the Nordics. To name just a few:

Open Science</li>
Design patterns in code</li>
The history of free and open source software</li>
Vim (yes, really!)</li>
3D visualization techniques</li>
Static web interfaces</li>
Peer review processes for reproducible research software</li>
RSE group structures, funding and career paths</li>
Data processing and (3D) visualization with game engines and other tools</li>
Training experiences in RSE and adjacent fields</li>
Data handling tools and techniques </li>
Graphical tools for working with supercomputers</li>
"Real-world" software engineering that can mess up someone's night in case of malfunction</li> </ul>
And then there were all the spontaneous conversations - during lunch breaks, over coffee, and at the conference dinner - covering even more ground. The small size of the conference made it possible for each person attending to meet (almost) all the other participants: this fostered a very constructive and dynamic environment.
Getting There</h2>
The lead-up to the conference was its own journey. Early on, we also ran a conference info event in form of an interview with the conference chair and local chair, which we summarizes as a blog post titled "Join Us at Nordic-RSE conference 2025: A Home for Research Software Enthusiasts!"</a>. Abstract submission was open until March 16, and we hosted a dedicated “Night of Unfinished Abstracts” on March 12 to help people shape their ideas and get peer support finalizing their abstracts and ideas. Registration ran until early May, all through our website</a>. 
Staying Involved</h2>
The conference might be over, but we’re always looking for ways to keep the momentum going - especially online. Do you have a suggestion for a seminar speaker? Have you got a topic you’d like to present? Want to help organize the next conference?
Join us in the Nordic-RSE Zulip chat</a> and help shape what’s next. Nordic-RSE is built from the bottom up, by RSE themselves for other RSEs.
Thank You</h2>
A heartfelt thanks to everyone who made Nordic-RSE 2025 happen:

Our code of conduct committee, Heli and Julia</li>
The organizing team: Matteo, Radovan, Luca, Richard, Jarno, and Samantha</li>
Our funders: the Software Sustainability Institute</a> and GRIDH</a></li>
And of course: every participant - for coming, sharing, discussing, and generally contributing to the great atmosphere that we felt</li> </ul> Want to Read More?</h2>
Here are a couple of reflections and highlights from others in the community:

Blog post by Michael Dales on insights from the conference</a></li>
LinkedIn post by InfraVis</a></li> </ul>
See you next year Tromsø, Norway, June 9-10 2026! 

The Nordic-RSE 2025 Organizing Team</li> </ul>

Join Us at Nordic-RSE conference 2025: A Home for Research Software Enthusiasts!

2025-02-28T00:00:00+00:00

Have you ever felt like the work you do in research software goes unnoticed? Like the infrastructure, tools, and coding behind scientific breakthroughs don’t always get the recognition they deserve? You’re not alone—and that’s exactly why this conference exists! </blockquote>
The Nordic-RSE conference is an event designed for anyone passionate about research software engineering (RSE). Whether you develop research tools, support scientific software, or are simply curious about RSE, this is the perfect space to learn, connect, and share knowledge. On February 27th we met with the conference chair Richard Darst and local organizer Matteo Tomasini to chat about the upcoming conference.
What is RSE and Why Should You Care?</h4>
Research Software Engineering is the backbone of modern research. It’s the coding, infrastructure, and tools that enable scientific discoveries—but often, it’s undervalued in academia.
As one of our interviewees put it: “RSE is everything research-related that isn’t just publishing papers. It’s about the software, the infrastructure, the tools that make research possible.”
Another described RSE as “a space for people who care about software and everything around it.” This conference is about celebrating that space and bringing together a community that understands the importance of research software.
What Makes This Conference Different?</h4>
Unlike traditional domain-specific conferences, this one is about:

Techniques over results – It’s not about presenting research findings but about sharing the methods, tools, and best practices that make research possible.</li>
A welcoming community – No gatekeeping, no pressure to defend your work. Instead, an open, friendly environment where people share what they love.</li>
A passion-driven approach – If you’re excited about research software, this is the place for you!</li> </ul>
If you’ve ever wanted to discuss research software without worrying about citations or academic critique, this is your chance to be part of a supportive, enthusiastic community.
Who Should Attend? (Spoiler: Probably You!)</h4>
This conference welcomes anyone interested in research software. You don’t have to be an RSE to join—just curious and eager to learn! Expect to meet:

Researchers</li>
Research software engineers</li>
Research support staff</li>
Infrastructure professionals</li>
Anyone interested in RSE, regardless of background!</li> </ul>
While we anticipate a strong Nordic presence, the conference is open to participants from all over. We’re excited to connect with both local and international attendees!
What’s on the Agenda?</h4>
This is up to you, submit your abstract until March 16th and be part of shaping the agenda!
We would love to hear talks and discussions on tools, techniques, and workflows; A showcase of everyday tools and techniques that might be new and exciting for others.
In any case, there will be plenty of networking opportunities to meet like-minded people and exchange ideas.
One of our interviewees shared: “Often, something that’s an everyday tool for you might be completely new to someone else. We could have a session where people showcase their tools & techniques in short talks or posters.”
The conference will feature a mix of high-level overviews and in-depth discussions, ensuring there’s something for everyone.
Why We’re Excited (And Why You Should Be Too!)</h4>
For many of us, this conference is more than just a work event—it’s a chance to meet like-minded people, learn new things, and strengthen the RSE community.
One interviewee shared: “The last event was my first chance to meet people in person and talk not just about work, but about our shared interests. It’s a great way to build meaningful connections.”
Others are excited to pick up tips and tricks from peers, gaining practical knowledge that can be applied immediately.
How to Join</h4>
Join us for the second ever in-person gathering of the Nordic Research Software Engineering community!

Dates: May 20-21 2025 (9-17 CET)</li>
Location: Gothenburg, Sweden</li>
Nordic-RSE conference website</a></li>
Abstract submission open until March 16th via the website.</li>
Support for writing your abstract at the "Night of unfinished abstracts" on March 12th from 15 CET to 17 CET. Get a calendar invite by providing your e-mail address in this short survey</a> or find connection details in our collaborative notes for the event</a> .</li>
Registration is currently open via the website. </li> </ul>
Sign up now and be part of a growing, passionate community that values the work behind the research. 
We can’t wait to see you there!

Small steps towards sustainable and open research - or why you should care about Research Software Engineering

2024-08-16T00:00:00+00:00

A blog post summarizing the outcome of a discussion at Nordic-RSE conference May 2024 (https://nordic-rse.org/events/2024-in-person-conference/</a>).
What is a Research Software Engineer (RSE)?</h4>
The short answer People striving for "Better software, better research" 
The long answer Definition of Research Software (from keynote by Martin O'Reilly) Research software is software that one use to generate, process or analyse results that is intended to appear in a publication. It can be anything from a few lines of code, to a professionally developed software package.
A Research Software Engineer is a person who combines an intricate understanding of research with professional software engineering expertise. RSE often have background in academia and have specialized in computing related areas, be it either software development, data analysis, (high-performance) computing, etc.
Independently of their area of expertise, their common goal is better maintainability, sustainability of research software and better reproducibility of research outputs. They introduce best practice tools and techniques to research groups by showing the benefits. They also teach them how to use them independently and support them in their adoption of the new tools and practices. They usually work in tight collaboration with researchers and help in finding the right tools and technologies for each project.
What an RSE is not
Even though they are in close collaboration with IT services, RSEs are not IT support people, as in IT manager or IT system specialists. They have a dual background (research/coding), they take part in research projects and speak the "same language" as researchers. 
Why would an organization need RSEs? - Current state of Research software</h4>
Does any of following scenario sound familiar? 

A PhD/post doc has developed some really nice piece of code, but they left and no one knows anymore how to run it or develop it further. </li>
Someone wrote some code long time ago that is used daily by a research group, but no one knows the technology in the research group anymore and it cannot be modified, updated or compiled anymore. </li>
When a newcomer joins a team and starts familiarizing with analysis/modelling/etc tools, the only way is to "ask others who use it". No document or tutorials are available. </li>
Some essential piece of software runs on a very old machine or on very old version of language and it's very difficult to replace or update, if even possible. This can even lead as far as stopping research activities in the team for some time </li>
After an article is submitted, one reviewer ask for additional analysis, or slightly different plots, but upon running the code again, one cannot reproduce the plots/results anymore. </li> </ul>
How can RSEs help research ?</h4>
Short answer
Improve the (re)usability of research software - including improving performance, reduce time and resource usage and ease on-boarding of new users.
Long answer
RSE can leverage all the above issues and more by accompanying researchers in their software development journey. RSEs' technical knowledge and creativity on solving problems allow seeing where researchers would benefit the most. Here are a few examples/use cases: 

Researchers have great ideas, but might not know how, or have time to develop the corresponding tools </li>
Help to get rid of repetitive or time consuming steps (that users don't want to do themselves) by introducing automatization </li>
RSEs know about the FAIR principles and can apply them to research software</li>
Write documentation so the information doesn't get lost when people leave</li>
Make the regular technology updates to prevent that it become obsolete and break</li>
Supporting when switching from laptop to compute clusters </li>
Many groups need the same thing, RSEs know how to create flexible templates to simplify e.g. spinning up a website to present research outputs</li>
… what other good examples? </li> </ul>
They can also act as intermediate in technical discussions about computing needs, as they know the needs of researchers since they are involved in research in a daily basis, and are also technology-aware people. 
As a summary, researchers with very deep expertise and RSEs with shallower but wider range of interests and skills complement each other very efficiently. 
How can organisations help RSEs?</h4>
Many organisations already have people doin RSE work, but the people and the organisation might not be aware of the term RSE. To give those people a sense of belonging and knowing that there is others like them, organisations could:

Support community involvement and self development

Give people room to be active in RSE communities, attend conferences and trainings beyond academic work.</li> </ul> </li>

Acknowlege RSE work

Consider other factors than authorship when evaluating the scientific output</li>
While the contribution of the RSE team/engineer might not be enough for a co-authorship, an acknowledgement in the paper can provide an adequate way to honor the work provided by RSEs</li>
Introduce this practice in your organizational guidelines and courses</li>
Provide example statements to acknowledge the work behind the scenes (e.g. "Code development and data management were supported by [names of your friendly RSEs or the RSE group].")</li> </ul> </li>

Spread the word - be an RSE ambassador

Recognize and highlight RSE (often behind the scenes and non-academic) work</li>
Invite RSEs to talk about their work</li>
Support RSEs building their own network within the organisation (connect them to administration, other RSEs, researchers, etc)</li> </ul> </li>

Make it a THING (administrative existance)

Hire RSEs</li>
If you have them already, gather them ("virtual team" or central RSE group)</li>
Offer support to spread good enough software practices in research groups</li>
Train the trainer events are important and needed </li>
Support formation of RSE groups by providing guidance about practices for forming a new entity in the organisation (group, service, etc) and finding the right integration points</li>
Share organizational knowledge on how get internal funding for RSE-type work</li> </ul> </li>

Funding

Inlcude RSEs at the stage of grant proposal writing</li>
Provide central RSE funding to support smaller projects and internal tool developments </li>
RSE benefits from open ended, non temporary funding - like other techical supports</li>
training and collaboration funding (e.g. EuroCC, EOSC)</li> </ul> </li> </ol>
Get to know more</h4>
Does RSE sound like something you would need in your organisation, or want to hear more about what RSEs in the Nordics are about, please reach out to us at Nordic-RSE</a>.
Other useful resources: 

Slides of the Nordic-RSE keynote by Martin O'Reilly on "The growth of Research Software Engineering and its vital role in research"</a></li>
Manifesto of the Software Sustainability Institute</a></li>
Article about setting up the industrial ecology digital lab, a small RSE group at NTNU, Norway</a></li>
Presentation about "lessons learned from running a local RSE group at UiT", Norway</a></li>
History of RSE group at Aalto University, Finland</a></li> </ul>
We would like to thank and acknowledge all the participants of the discussion "Why should organisations have an RSE/RSE group?" at the Nordic-RSE conference 2024 in Espoo, Finland.

Insights from the first Nordic-RSE conference in May 2024

2024-07-12T00:00:00+00:00

The first Nordic-RSE conference in May 2024</h1>
On May 30th and 31st of 2024, the Nordic-RSE community met for the first time in person on the Otaniemi campus of Aalto university in Espoo, Finland. After we had originally planned to meet in Stockholm in 2020, we were happy to finally get together in the same space as a community. While Nordic-RSE has continued evolving in the last 4 years, this conference in many ways felt like an official kick-off for the association.
The team behind the scenes consisted of Nordic-RSE members from Sweden, Finland, Norway and Denmark. Together, they have been planning and preparing the conference for about six months. We were incredibly lucky to receive sponsoring from the Software Sustainability Institute</a> and Aalto Universtiy. This event would not have taken place without their support, and we are forever grateful. Furthermore, discussions with organizers from other RSE conferences, such as RSECon and US-RSE, helped us a lot to prepare for this event. Thank you so much!
Participants to the conference came from seven countries (Denmark, Estonia, Finland, Norway, Sweden, Switzerland and United Kingdom) and from a number of scientific backgrounds. They were employed at all levels ranging from students to researchers, from junior RSEs to RSE leaders. 
The event started on Thursday with an informal introduction session where each one of the 28 participants could create their own name tag and get to know each other in relaxed and loosly led group conversations. The first Nordic-RSE in-person conference program officially started after a lunch break, but lively discussions among the participants had already started before and during lunch. 
In the opnening session, Nordic-RSE was presented in detail, describing the long path that led from its conception, through its foundation, to finally meeting physically in the same room for this conference. At the end of the first day, we met for dinner at a restaurant on campus, and afterwards- in true Finnish fashion - we moved across the street to the sauna where the bright summer evening continued. 
Martin O'Reilly from the Alan Turing Institute in the UK, representing the Software Sustainability Institute, opened Friday morning with a keynote talk. He talked about the growth of Research Software Engineering and its vital role in research. 
Eirini Koutsaniti from the Swiss National Supercomputing Center followed with a second keynote talk about enhancing HPC service management. 
The submitted conference talks ranged from experience reports to tool presentations and demos. You can find all abstracts of the conference in the Nordic-RSE conference 2024 book of abstracts</a>, and the few public notes that were taken at the conference, along with some slides, on the event HackMD</a>.
As this was the first such conference that we held, we had the chance to hear a lot about how the creation and leadership of RSE groups from Aalto University, the Arctic university in Tromsø and NTNU in Trondheim, and about infrastructures such as InfraVis in Sweden and CSC in Finland. 
In the afternoon of Friday we dedicated time to workshops and discussions: the first discussion started with another introduction round, this time focusing on the relation to RSE and how supported everyone feels in their organization. After that we split into groups and discussed around the question "why should an organization have RSEs?". The results of these discussions were summarized in another blogpost titled "Small steps towards sustainable and open research"</a>. In the last discussion of the conference we started collecting feedback and planning the next conference. 
Nordic-RSE conference 2025 will be arranged in Gothenburg and you can be part of the planning team by joining the discussion on the Zulip chat</a> (channel #nordic-rse-2025).
During the whole conference we had an open board to collect ideas for logos for Nordic-RSE. Currently the Nordic-RSE association uses the general RSE society logo with Nordic added before it. However, the community agrees that it would be nice to have something of our own.
We would like to thank all participants and organizers of the conference for a successful event and hope to see many of you in 2025 in Gothenburg, Sweden!

Imp-RSE-sions from SuperComputing conference 2023

2023-12-06T00:00:00+00:00

SuperComputing conference 2023 in Denver</h2>
"SC23 Welcomed Over 14,000 Attendees and 438 Exhibitors Setting SC Records on Both Counts" (from SC homepage</a>).
And indeed, a little overwhelming it was, but getting lost in the many hallways of the Colorado conference center was one of the best icebreakers to start talking to random people. However, following mostly the smaller events of the conference, like BoFs and workshops, it never really felt too big or anonymous.
It was sometimes difficult to choose between multiple relevant and interesting sessions happening at the same time. But we also tried to "parallelize" and below we summarize our impressions and notes.
"I am HPC"</h3>
The topic of this year's SuperComputing conference was "I am HPC" and this showed in many of the keynotes and panels that were presented, as well as a wonderful exhibition of previous conference themes and highlights and some posters highlighting different key people stories in HPC.
Democratizing HPC workshop</h3>
This was a great workshop and we had the chance to see two outstanding presentations (while unfortunately missing the other presentations in this session when jumping to other sessions and meetings):

The History and Future of Making HPC Technologies Accessible to the Wider Community</a> by Al Geist.</li>
Democratizing Science through Equitable Access to Computing and Data</a> by Manish Parashar.</li> </ul>
The second presentation cited this important document: The Missing Millions</a>.
Research Software Engineering</h3>
Even though this conference is so large, it is nice to see a lot of the same people in sessions of interest. One of these groups are the Research Software Engineers. US-RSE had a booth in the exhibition area and luckily collected a list of all RSE-related talks and sessions of the whole conference, and also organized a social gathering.
In some meeting we learned about a wonderfully curated list of lists for RSEs by the Helmholtz Federated IT Services (HIFIS): https://github.com/hifis-net/awesome-rse .
RSE in HPC workshop</a></h4>
The UniverseHPC project</a> (providing training for RSEs in HPC) developed a nice looking framework for delivering courses and materials from markdown with metadata in yml</a>.
A portal for scientific software discovery: Virtual Institute for Scientific Software</a>.
Scientific Software and the People Who Make it Happen: Building Communities of Practice</a></h4>
This was a second edition of this BoF (previous editions</a>) with a welcoming community and interesting and inspiring lightning talks.
Among others, there was a lightning talk about RSE as a career path, introducing a brochure on the topic by US-RSE (Research Software Engineers: Creating a Career Path—and a Career</a>) and a talk on the European Environment for Scientific Software Installations, introducing the EESSI software stack</a>. 
Panel on RSE in HPC centers</h4>
Some notes from the panel discussion hosted by Daniel S. Katz, with Gabrielle Allen, Neil P. Chue Hong, Alison M. Kennedy, Fabio Kon and Miranda Mundt:
What are RSEs:
* Bridge between scientific requirements & computational constraints / HPC novice & computing infrastructure * Stewards for computational resources * Advocates for better software practices * Mentors, trainers, educators * Quality gates for scientific software </code></pre> It was also mentioned that ideally an RSE in HPC should have at least 2 of these skills:
* Knowledge of best software engineering practices * Domain specific knowledge * HPC </code></pre> -> sometimes better if there is a mixed group of RSE, each with 2 of these skills working together Some issues/challenges that RSEs in HPC face:
* Lack of diversity (from domain perspective) * Lack of possibilities to develop interpersonal and communication skills * More work with the researcher instead of work for the researcher (leaving the R in RSE) * How to keep RSEs relevant in funders/organizations eyes * Salaries (same skillet earns much better in industry) * Status: RSEs often seen as inferior to researchers (researchers question to include RSEs as authors in publications, because of "just" doing software, not the "real" research) * More training possibilities needed to develop own specialization within HPC * Recruitment: title still not known enough * Retention due to eg lack of recognition * Promotion: lack of official titles and career paths * Often spread all over: need high level advocate/coordination </code></pre>
Training (HPC and related)</h3>
From FAIR HPC training meeting: Project started to collect HPC training materials, discussion on minimum metadata ongoing, but probably good to follow as material metadata needs to be submitted manually: https://hpc-ed.github.io/</a>. Similar efforts ongoing in Australia (Automatic web scraping): https://dresa.org.au/</a> .
Workshop on best practices in HPC education and training</h4>
A lot of talk about how to making it easier and incentives for training developers to share materials. "Sharing by design" is wished.
IQM had a wonderful lightning talk about their IQM Academy material, talking about the importance of focusing on fundamental concepts to get learners ready for the real world rather than teaching tools that are changing all the time. In their training material they provide exercises solutions via tabs for different tools that can be used. (Example: https://www.iqmacademy.com/curriculum/foundations02.html)
The concept of Code-a-thon was introduced: Learning by doing, starting with a simple "story" and letting learners develop the code. Introducing more complexities in the "story" with every step and let students further develop their code. In that way the students knowledge can grow with the code, instead of having a huge task to start with that is introducing multiple new concepts at once. 
Another interesting resources we learned about: Cornell virtual workshop: https://cvw.cac.cornell.edu/</a>
HPC certification forum</h4>
Call to action and request for contributions from the HPC certification Forum: They have started defining a skill tree and examination questions to provide a framework for HPC skill certification. Skill tree: https://www.hpc-certification.org/wiki/skill-tree/b</a> as tree: https://www.hpc-certification.org/cs/map/</a>.
An example for how a learning roadmap could be presented: https://roadmap.sh/</a>.
Fun ideas for outreach and teaching HPC</h4>
This was a super nice BoF on designing HPC outreach activities with wonderful ideas on especially how HPC and scientific computing can be brought to different age groups. Some activities can be found here: https://edin.ac/3Z0ZJ34</a> .
Ideas/suggestions/inspirations collected at various workshops and BoFs:

Nice example to practice parallel programming with randomness: Nagel–Schreckenberg model</a>. Try to make it reproducible and parallel.</li>
Parallel color-by-number.</li>
Parallel puzzle solving.</li>
Teach machine learning with tic-tac-toe as example with reinforced learning.</li>
Distributing a problem with coloring.</li>
Practice parallelization by sorting objects into buckets with several people.</li>
Scheduler explained with Tetris.</li>
Results from Outreach BoF: https://tinyurl.com/outreach-activity-design</a></li> </ul>
ACM SIG Education</h4>
The ACM SIG HPC education chapter had an informal meeting that we joined out of interest which seems like a nice forum for exchange around HPC education at universities and centers around the world: https://sighpceducation.acm.org/</a>
Collaborations and contacts</h4>
With CodeRefinery we connected with projects Better scientific software</a>, Universe-HPC</a> and INTERSECT</a> to discuss how to work together and exchange experiences/helpers/materials. We agreed that it is crucial for sustainability of all the awesome stuff that comes out of each of these projects, so we agreed stay in contact.
The RSE social event was also great to do some networking with RSEs from around the world. Got lots of insights and contacts to US-RSE and the Software Sustainability Institute in UK, which will help a lot in organizing first Nordic-RSE conference next year and further developing Nordic-RSE to be a welcoming and active community.
We also talked to HPC Carpentries. They know that people are reusing their materials through forks and adapting it to their needs, but no one ever shares their changes back. Mostly this seems to be a problem of wanting to make the materials "ones own" and not being sure if it can/should be reintegrated. Also it is a lot of work to review and make decisions on what should be reintegrated, to keep it all general.
The women in HPC community is steadily growing and providing lots of opportunities for mentoring , learning, career coaching etc with the mission to increase general diversity and make anyone feel welcome in the HPC community. They had a full day workshop and own reception. So instead of the general tracks it was also possible to submit a talk/poster to their session. Highly recommended to follow them on social media if that is your kind of thing :)
Own contributions</h3>
Two of our proposals were not accepted but nevertheless we were fortunate to participate in three very inspiring sessions:

Radovan presented Research Software Hour</a>, at Scientific Software and the People Who Make it Happen: Building Communities of Practice (SC 2023 BOF)</a>.</li>
Samantha was part of a workshop panel on training and mentoring, based on CodeRefinery experiences (workshoplink</a>)</li>
Samantha co-organized a BoF session on HPC learning pathways, which was great success with almost full house (some 70 people) and a lot of great feedback and discussions going on. It's a tricky topic, we will report the results in Jan/Feb to ACM HPC SIG education and training Chapter and write a blog or something to share the results. There was also requests for more of this type of BoF or workshop in similar forums like ISC etc.</li> </ul>
We submitted one tutorial which would have been about showing the CodeRefinery way of providing hybrid training in FAIR research software development practices. However, the proposal was not accepted due to being not timely and thought through enough (but in total did not get too bad reviews). We are planning on trying again next year, maybe with slightly different focus.

State of Research Software Engineers on Mastodon

2023-08-08T00:00:00+00:00

Many domains have migrated to Mastodon as of 2023. Have Research Software Engineers? This post examines the situation, based on this post by rkdarst</a>. There are many contributors to this post as seen in this issue</a>.
Summary: not much yet
This post can be updated as we get more information/the situation evolves, please send pull requests.
RSE organizations</h2>

US RSE: https://fosstodon.org/@us_rse</a></li>
DE RSE: https://mastodon.social/@de_rse</a></li>
Nordic-RSE: https://fosstodon.org/@nordic_rse</a></li>
Society of RSE (UK/int): ??</li>
Research Software Alliance: https://fosstodon.org/@researchsoft</a></li>
Netherlands eScience Center: https://akademienl.social/@eScienceCenter</a></li>
RSE Midlands https://mastodon.social/@RSE_Midlands</a></li>
... ?</li> </ul>
Other accounts to follow to seed your community</h2>
TODO: We should try to get a category in https://fedi.directory/</a> rather than make our own list.
Common hashtags</h2>

#RSEng and #RSE have been seen, but #RSEng is preferred (ref</a>. There doesn't seem to be much activity there. #RSEng was the primary tag from from Twitter. Sometimes #RSE is the people and #RSEng is the activity. </li>

#HPC has a fair community. </li>

#OpenScience can be found, in addition to ResearchData and ResearchSoftware. </li>

We propose #SciComp as a general "scientific computing" tag which can partly overlap with the above, but is more general to people interested in the computing part of science. </li>
There is the a.gup.pe</a> group "researchsoftware", which will boost any post tagging it, and can be used as a more targeted distribution group than tags (ref</a>). We could also get a listing at https://fedi.directory/</a>. </li> </ul>
RSE-focused Mastodon servers</h2>
There don't seem to be any servers specifically focused on the RSE community. Perhaps the closest one is the HPC community https://mast.hpc.social</a>, and we are invited to take part there (ref</a>). There is overlap between the HPC and RSE communities, and the initial community survey (ref) for creation of the HPC.social Mastodon server showed a significant interest in exchanging information on software topics.
Many of the repliers used https://fosstodon.org</a>.
One could ask if it's better to have a common server, or be more distributed among the communities of other scientists to spread the word. There is a list of academic/science related servers at fedi-science</a>. The primary advantage of a topic-driven server is a better local timeline, which will be populated with the posts of everyone on that server. While following hashtags/etc. is similar, the local server makes this more natural.
There could be room for some RSE organization to set up a RSE-focused server. (editor note: I, rkdarst, would somewhat prefer a "scicomp"-focused mastodon server to bring together data, computing, software, etc. people. Yet, this is also too broad and nebulous and without organizational backing so comments were negative on this idea.)
Future</h2>

Please send pull request with updates.</li>
We should contact SocRSE UK and ask them if they are interested in a Mastodon community.</li> </ul>

Summary of the first Finnish RSE meetup

2023-06-12T00:00:00+00:00

The first Finnish RSE meetup was held on 30. May 2023 at Dipoli, Otaniemi. About 15 RSEs and RSE interested people joined in person and online. 
We started with an introduction round, where everyone could tell about their background and vision for RSE in Finland. The consensus for the future of RSE in Finland was to build a community for experience exchange and collaboration, and the meetup was a great first step into that direction. 
We then tried to define what is an RSE by discussing what it would mean to leave out either of the letters in the term RSE.
Aalto RSE group</a> and RSE activities at CSC</a> were introduced, as well as the activities of Nordic-RSE</a> and the CodeRefinery project</a>. Presentation material can be found behind the links at each name.
The vision of a community based RSE support was introduced and discussed. Many places/services nowadays have their own virtual office hours / garage session / user support coffee breaks. How would a RSE garage look like, would it be useful and how could it be realized?
You can find the full event notes here: https://hackmd.io/@nordic-rse/fin_rse_meetup
We concluded the day by summarizing our goals and needs for the future of RSE in Finland:
What would we need from management levels?

Cost object with funding for future RSE development activities</li>
Enable cross-organization RSE collaboration, that allows sharing work-time</li> </ul>
What could RSE-RSE collaboration and support look like?

Occasional consultations on a technology you happen to know

Cross-organization garage pings</li>
Consider joining CodeRefinery chat and talk about cool stuff you do / ask questions to other RSEs

#nordic-rse (about the org and RSE life), #TIL (cool stuff you do/build), #help (asking for help/answering), #general (misc), #finland, streams</li> </ul> </li>
Submit ideas to and attend the Nordic-RSE seminar series (self-development)</li>
Low barrier to sending messages</li> </ul> </li> </ul>
Things that we can do ourselves:

Update Nordic-RSE page to make it clear why / what activities someone should join (e.g. seminar series, chat).</li>
Talk to others about how cool this meeting was</li>
Work on spreading the info from our chats a bit more (dedicated channels in internal chats)</li>
Local FI meetup around the time of the Nordic-RSE unconference in October '23 (more info to follow)</li> </ul>

Take the 2021 international RSE survey: help us improve the RSE community

2021-11-30T00:00:00+00:00

Take the survey</h2>
Do you develop research codes, or generally work with research software or data analysis? Perhaps you even feel more connected to the technology side: programming, software, data, etc., rather than the writing of papers? Although this work is crucial to the research, the modern research environment seldom fully recognizes it, in contrast to other methodology development. Take part in the international Research Software Engineer (RSE) survey</a> to help us understand how we can improve the situation. Your current position or job title does not matter, only that you feel connected to software, data, computation, or similar technology.
Link to the survey: https://softwaresaved.limequery.com/386272?lang=en</a>
You can also help us by sharing the survey with others</h2>
Perhaps you are not writing research software as part of your work, but maybe your colleagues or collaborators are? Or perhaps a research group or research institute that you are in contact with? You can help us and the reach of the survey immensely, by sharing and making the survey more visible in mailing lists, group chats, blog posts, or newsletters. There are many RSEs out there who may not know about the RSE community, and that there are many more RSEs working across the Nordics/Baltics (and in the rest of the world). Many are not even aware about the term "Research Software Engineer"</a>, and that they are one. This survey is one way to reach them, and to raise awareness.
What and who is an "RSE"?</h2>
A Research Software Engineer</a> is a person who combines the mindset of a researcher with the skills of a software developer. We interpret this inclusively, for people who might consider themselves data engineers, system specialists, and so on. For decades, research has been dependent on such roles, but without providing them proper career support or recognition. The Research Software Engineer movement aims to improve this situation by representation and advocating for these people and their work.
RSEs in the Nordics and Baltics</h2>
Nordic-RSE</a> is the Nordic+Baltics association advocating for RSEs. Founded in 2017 and registered in Finland in 2021, it provides a community</a>, periodic seminars</a>, and in the future other events</a> which can connect RSEs to like-minded individuals and promote career development. It will also advocate for the value of RSE services within the research process.
Why the survey matters</h2>
The survey is run worldwide every two or three years by the national RSE associations</a> together with the Software Sustainability Institute</a>, with the aim to provide a better understanding of the RSE community, and the environment in which research code is developed in. This insight is invaluable when trying to improve the situation for RSEs, and when applying for support from national associations, funders and other policy makers. The data from the survey is anonymized and published openly.
The 2018 survey</a> was completed by nearly 1000 people around the world, providing a useful overview of the RSE landscape. For example, it allowed us to assess the average background, experience and primary disciplines of RSEs. Alarming results were found in terms of gender imbalance in all regions, and 50% of RSEs reported a lack of proper recognition or acknowledgement of their work. Hence, the survey provides important and substantial results to point towards in our interaction with universities, institutes and the policy makers.
The survey is being conducted with ethics approval from the University of Southampton (ERGO ethics application number: 65619). The first page of the survey tells you everything about the conduct of the survey, our approach to privacy and data protection, and your rights as a participant in the survey.

How to be a 'good' git evangelist?

2021-09-02T00:00:00+00:00

Text credit
This text is based on the notes from the community discussion 'How to be a 'good' git evangelist?'</a> which took place during the online Unconference event</a> of the Nordic RSE community on the 29th of June 2021.
The modern scientist's toolbox</h2>
Basic usage and skills of computational knowledge are becoming more and more important in academic fields. Both the biologist, physicist, psychologist, and the economist are expected, to some kind of extent, to know how to use and write small scripts to accompany their scientific arguments. To do this in a successful way 'good' scientific software is needed.
A definition of computational science. Figure credit</a>.
'Good' scientific software does not have one clear definition. Dependent on the discipline and field you will get different answers. Some main points that most users/developers of scientific codes would agree upon are that 'good scientific software' is something that is:

working</li>
standardized</li>
understandable</li>
reproducible</li>
maintainable</li> </ul>
One way to measure code quality. Figure credit</a>.
To help the user/developer accomplish 'good' scientific software there exist several modern tools. Some of these are:

version control systems (VCS)s</li>
documentation (in code, Read the Docs</a>, examples, etc.)</li>
modern editors</li>
proper debugging tools</li>
containers</li> </ul>
All of them are important in the modern scientist's toolkit but seen from the RSE perspective the deployment and usage of VCSs are often not taken advantage of in scientific domains where coding and software itself is not the deliverable.
This text aims a giving you some techniques or arguments you could use to convince your team that it is time to invest in learning to use version control. We also explore some of the broad tasks that can be more easily accomplished with the usage of modern VCSs and make the daily life of the modern scientist easier.
How can scientists be motivated to learn to use version control?</h3>
According to Wikipedia</a>, the first deliberate revision control system was published in 1975. Modern version control is most popularly used for tracking changes in a codebase over time. For this reason, there is also reason to think that this is the only type of task which is relevant to use VCS for.
How can scientists be motivated to learn to use version control?

Ability to use advanced regret button. The first introduction to version control on a computer is done by pressing ctrl+z in a gmail or office document. When writing or collaborating on a longer text, the nightmare before version control</a> or having folders with documents like version_final_x_modified_PI_comments.docx, x=[1, 2, ...] quickly becomes a mess. </li>

Automatic backups. Remembering to take a backup of your work in progress and keep safe copies is an extremely good idea if your computer crashes, dies, or gets stolen. To complete a typical master thesis in a modern university will contain some kind of scripts used to construct a lot of figures and plots made by changing or commenting in and out some lines of code. If properly explained and introduced, VCSs can be used to track these changes so one never needs to wonder about which configuration that made that figure. You can keep track of changes in a document, for instance, TeX, logging your daily work, and collaborating with your colleagues. </li>

Better platform for collaboration. The moment the coding work is shared with colleagues there is a need for a platform for sharing files and scripts. Sending zip-files over mail is not a modern or ideal way of sharing code. </li>

The experimental analog: If you were doing a scientific experiment, would you ever trust your instruments if they were not calibrated? To have a successful experiment you will need the right tool for the right job. When touching something data scienceish on a computer, settings for versioning is essential for reproducibility. </li>
You will probably need it later to be taken seriously. Most of the students taking a master or PhD today will not stay in Academia. If one decides to join the industry or another part of the real world, academic programmers are not known for good quality on their academic software</a> or scientific code</a>. To be taken seriously as a software engineer or data scientist the use of VCS is a critical tool. </li>

A way to track unforeseen consequences. If something is changed somewhere in a code base/script it can have unforeseen effects in other parts of a project. Without VCS it is difficult to know when we have introduced such problems or solutions. In research projects these changes are usually something we need to know since the changes affect our thinking and conclusions which again can/will affect other research projects. It's not good enough to say "well it got fixed at some point. let's just be happy that it is correct now" </li>

A way to track unforeseen consequences. If something is changed somewhere in a codebase/script it can have unforeseen effects on other parts of a project. Without VCS it is difficult to know when we have introduced such problems or solutions. In research projects, these changes are usually something we need to know since the changes affect our thinking and conclusions which again can/will affect other research projects. It’s not good enough to say “well, it got fixed at some point. let’s just be happy that it is correct now”. </li> </ul>
How can we be 'good' git ambassadors in our communities?</h3>
In the days before markdown and sleek web interfaces version control was a tool for the dedicated developer. Today, there exists a broad range of modern graphical user interfaces that simplify the mysteries of branches and merge. Convincing people that the time invested in learning to use these modern tools will pay off is a big part of the RSE job.
How can we be 'good' git ambassadors in our communities?

Enforce the use of technical solutions. If someone asks you for help you could provide the solution via GitHub/GitLab/Bitbucket/etc. Embracing one of the nice and modern web interfaces like Github can take away a lot of the complexity for beginners. Remember that you might need to provide some assistance with how to use the platform. </li>
Promote workshops. Share workshops like Coderefinery</a> and Software Carpentry</a> with students and colleagues can lower the bar to get people to start using VCSs. </li>

Use (positive) social control. Among same or similar level researchers and RSEs it is easier to make suggestions like starting to use git. Even in the fields where the researchers do not develop their own code, but only use software written by others, there is a potential to use VCSs to simplify their daily work. One could use VCS to track the different kinds of experiments conducted when they run code. Changing one parameter, changing to another parameter, etc. </li>
VCS helps the reproducibility of research. There are starting to come requirements from journals and conferences on the reproducibility</a> of code used in scientific settings. By enforcing good standards as early as possible one are sure to be good enough when this is actually needed. </li>

Convince the authorities. As an individual alone, it can be very hard to convince colleagues to understand why they should invest in learning version control. With the authorities are onboard you can make your life easier. Younger individuals in academia (young post-docs, PhD and master students) are easier to convince than the older generation (permanent staff like researchers and professors). </li>

Make it a requirement in research grants. In our modern scientific world, a common task differentiation is to give the programming job and the details to the youngsters let the older generation handle the overall picture and long-term planning. As a result, there is still quite common in academia that people working with code today do not use VCS because their supervisors did not use it in their work and they are not encouraged to invest their time to learn how to use this tool. If the principal investigators for research grants can be convinced to require researchers to work a particular way, it can be very effective to tip the standards in a good direction. </li>

Make it a required skill for individuals. Include experience, or the willingness to learn, VCSs a requirement when hiring new people in the group. </li> </ul>
When should we learn to use VCS?</h3>
From an RSEs perspective version control could easily be introduced right after the first code line successfully prints hello world</code>, but it is not useless to learn at any other point.
When should we learn to use VCS?
From the beginning. Most students will start their programming career by writing small scripts or completing examples. By introducing VCS at the same time the complexity of the usage can grow with the learner's needs. </li>Wait until needed in daily work. It is hard to imagine an effective and successful code collaboration between more than one person without having some rules for contributions etc. Waiting until one sees the need for the tool can also be a good strategy. Maybe not all projects need to use a VCS, but at the point where one starts to collaborate with other people, VCS is extremely useful. </li> </ul> How and who should teach VCS best practices?</h3> There are workflows that are considered as standards and certain forbidden commands one should not use when working with VCSs. How and who should teach VCS best practices? Typical git usage in a nutshell? Figure credit</a>. Include VCS in university courses VSC or Git can quite easily be included as a smaller part of a Python course + Git as a part of a scientific software development practice course. Based on experience it is important to make the learners repeat what they have learned in other settings where they can continue to use the tool for their own needs. University courses that have coding exercises could choose to use a collaborative platform where the students can clone repositories and submit answers. The learners would then start to use version control in a setting where it can not be questioned. For students at the PhD-level, there are usually a certain amount of credits that must be taken. By integrating git in the curriculum all students will hear about git at one point. </li> Volunteer learning initiatives. Workshops and courses hosted by organizations like Coderefinery</a> and Software Carpentry</a> are great examples of settings where learners in communities without RSEs or technical competence in VCS could get hands-on experience and start working. If you have the capacity to give a hand, like being a helper</a>, host or instructor, you can </li> </ul> Summary</h2> If you are an RSE preaching git to colleagues you can try to use 'good enough' practices for scientific computing</a>. Remember that every scientist does not need to master all aspects of VCS to make use of it in their daily work. In the RSE church, it is effective to preach 'good enough' scientific software. Figure credit: Michele Rosenthal.
Seminar report: Package Development in Julia 2021-08-18T00:00:00+00:00 On August 18th 2021 we started our (to be) monthly Research Software Seminar Series with Luca Ferranti from University of Vaasa giving insights in Package development with Julia. 9 interested learners + host and speaker joined the zoom call for about 3 hours. Luca had set up the session in a way that everyone who wants can type along with him. All material can be found in this github repository</a> and the Agenda and Q&A here</a>. Topics captured were the Julia REPL and how to use and create environments. Luca showed us his general workflow for creating packages from scratch, which gave a good starting point for people to develop their own Julia packages. Also tips and tricks for testing and documenting Julia packages were covered. Nordic-RSE thanks Luca for a super interesting and engaging seminar workshop! The recording of this seminar will soon be available on Nordic-RSE youtube channel. How to get funding for software projects 2021-08-11T00:00:00+00:00 Part A: Where and how to get funding?</h3> There are some guides about funding of open source software projects: https://opensource.guide/getting-paid/#finding-funding-for-your-project</a></li> https://github.com/nayafia/lemonade-stand</a></li> </ul> They can give a general overview for open source funding. They might have value for existing projects that need continuous funding as these projects by demonstrating their use (Letters of support, Download/usage statistics, citation count etc), have a better chance of convincing external funders of the value they generate (even if only for the academic community). For funding requests supporting existing projects it might also help to detail what will be improved, what features will be added, and how the maintenance benefits the quality of the project. However, in general it seems easier to obtain funding for new projects, since it seems that 'novel' ideas tend to be of greater interest for public funders. Here, we will list several existing options for funds for software projects in (but not exclusively) academic settings: For quantum projects, https://unitary.fund</a> is a source of small (4000€) grants, that might be easily accessible. For visibility and project improvements, Google Summer of Code</a> and tweag open source fellowship</a> offer a great way to get interested students, or with tweag even more professional coders into the project, test their potential (e.g. for a later masters/PhD) and get new contributors for a project. However, the support is for a rather short time (12 weeks). In Germany, the DFG sometimes puts out calls for research software (e.g. 2016 call for sustainable research software development</a> or 2019 call for quality management in research software</a>) Part B: How can we get more funding for scientific software?</h3> Overall, we got the impression, that many software projects are funded by being hidden within larger grant proposals. While this works to get some funding, it leads to an undesired invisibility of research software development, which makes it difficult to get funding for projects. On the other hand decision makers seem to be aware, that software is necessary, and there are even calls which explicitly ask for details on what software funding there will be. As such, it seems important to get grant-writers to stop the practice of hiding or obfuscating software development in their grants but to explicitly list them in the requirements and/or goals of the grant. To achieve this it would also be important to convince PIs that proper funding for research software development is important, and present the advantages of having permanent research software engineers. Those include (but are not limited to): A RSE stays, and thus the knowledge about the code remains in house for future reference</li> A RSE has a higher incentive to produce higher quality code, that stays useable even if they leave the institution</li> Code development can be sped up if a RSE serves multiple groups by not having to replicate the same code multiple times (in contrast to individual PhDs/PostDocs who only code for "themselves")</li> </ul> A further argument, which needs some more work could be the time saved by employing RSEs. This would require a survey of PIs on how much time they, or their group spend on code development, and an estimate of how much time could be saved by employing specialists for some of the tasks. This data would also be important for higher level decision makers in order to show the value of RSEs in research. To this end, it would be good to obtain more and clearer statistics to demonstrate use and visibility as mentioned above. For some languages, download statistics can easily be obtained by package managers (e.g. conda/pip for python): Pip Download badge for git</a></li> Conda download badge for git</a></li> </ul> We would need to check to what extend these are available for other languages. Another important thing to remember is to make citing software easy by putting it into code (e.g. a cite function), into the documentation, and in general make it easily findable (since often a lack of easy citability will lead to fewer citations). And in the end, citations are an important way to prove impact for future funding. Research software journals 2021-08-11T00:00:00+00:00 Why research software papers?</h2> Publications is the currency of researchers. To receive fundings or progress in the academic career path (e.g. getting a tenure track positions) researchers are (among other things) judged by their number of publications, the number of citations they have received and on what forum their work has been published. What about those people spending most of their time developing a research software? It is true they are not producing new scientific result, nevertheless their work is fundamental to conduct research in a transparent and reproducible way. How can they get credits from their work being used by several researchers around the world? Sure they can archive their code repository to Zenodo and get a DOI, but several platforms (I'm looking at you Google Scholar) do not count those publications and the citations, as they only value papers? The solution is thus software papers, a paper giving a short description of the software that can be cited by other researchers. Advantages of writing a software paper</h3> Citable, citations are researchers currency</li> increases visibility of the software</li> Review process has to check the software -> improves reproducibility of science</li> </ul> Why not just Zenodo?</h3> Not recognized by several citations counting tools, e.g. google scholar</li> </ul> Challenges in publishing software papers</h2> Fair recognition of contributions</h3> List of authors fixed, what if someone joins after the paper was published but still does a significant contribution?</li> </ul> How are software papers seen?</h3> Unfortunately, in several countries research software journals are still seeen as "minor" publication forums and are not as respected as other traditional journals.</li> </ul> Some research software journals</h2> Journal of Open Source Software (JOSS)</a> peer reviewed</li> open access</li> no fee</li> </ul> </li> Journal of Open Research Software (JORS)</a> peer reviewed</li> open access</li> publication fee, but can be waived? see here</a></li> </ul> </li> software-X</a></li> Geoscientific Model Development (GMD)</a> open peer reviewed</li> open access</li> publication fee</li> </ul> </li> Applied Physics Reviews</a></li> </ul> Did we miss some? Send us a pull request! Unconference 2021 2021-08-11T00:00:00+00:00 Although the world situation prevented our plans to meet the community in person in Stockholm and we were all busy with other works, we did not want to give up meeting the community this year. Thus we decided for the unconference/birds of a feather format to keep organizational hassle low, but still give the community a place to meet, learn, and discuss. In that way, the community could decide on the topics of interest and create an event to their liking. The event was held on June 29th + 30th 2021 afternoons. Three speakers were invited beforehand to talk about their interesting work, the rest of the event was free for the community to fill. Shahnawaz Ahmed from the Wallenberg Centre for Quantum Technology talked about the journey of his Quantum Toolbox in Python (QuTiP) from small research project to open source project developed by a community from all around the world.</li> Kristoffer Carlsson from JuliaComputing introduced Julia for research software.</li> Anne Fouilloux from Nordic-RSE gave some insights into myths and misconceptions about research software development in academia that she encountered during her work as an RSE. The event had 69 registrations from 7 countries (FI,NO,SE,DK,UK,DE,NL). Topics ranged from broad (Introduction to Julia, What is R/S/E?, ...) to specific ( Funding for software projects, Development frameworks, Software paper publishing,...) with lots of Q&A and discussions. You can find schedule and notes here</a> and stay tuned for more blogposts (https://nordic-rse.org/blog/) and recordings of the invited talks coming in the near future. Since this was the first event of this format, we learned a lot in the process. We definitely want to organize this kind of event again, but will try to bring a bit more order into the submission and decision of talks and discussions. Another suggestion we got was to encourage last minute contributions by having more own contributions since it is easier to add the tenth suggestion to a list of nine suggestions rather than adding the first.</li> </ul> What is 'R'? What is 'S'? What is 'E'? 2021-08-11T00:00:00+00:00 Who is considered an Research Software Engineer (RSE)? This has surely been discussed plenty, but at the unconference we had our own little chat about it. Perhaps as you might expect, we didn't come up with any amazing answers. However, we did make a summary of what happens if you remove each term from "RSE", which perhaps provides the most insight we found. Remove Research (Software Engineer)</h3> Research is more explorative and unknown (and requires more creativity) than following a specification. It is not only doing "the research" but also other things that support research or research infrastructure. There didn't seem to be strong opinions that it had to be academic, but this wasn't a major discussion point. If you hire a software engineer instead of a RSE, you might not have practical research value (or might right now but not in five years). You might miss open science, reproducibility, flexibility, and it might not be easy to modify and reuse by other researchers who don't have as deep of software training. Remove Software (Research Engineer)</h3> In some ways, "software" is the trickiest term to define. Of course "software" is obvious, but in practice our community is not only about software but about specialist support of computing in general. Its seemed that most of the attendees took a broad view of software: it doesn't have to be just directly software used for research or large, but could be (for example) other infrastructure software or small things. Perhaps more ambiguous are roles such as data engineers/data manages/computer cluster administrators. There wasn't any motivation to exclude people like this, though their skillset would be slightly different (though it's important that we all share some of the basics!). At the very least, these are people that we can very well include in our community of specialist research supporters. If you hire a Research Engineer instead of a RSE, you might expect that they are not computational. These days, lacking other named communities, a RSE could very well be a data engineer, or focus on computational infrastructure, or a wide variety of other similar topics. Remove Engineer (Research Software Person)</h3> In some localities, "engineer" is a licensed profession or degree. While we acknowledge this, it didn't seem to be the dominant factor in our definition. "Engineer" can also be a particular degree title, but that was also not a significant factor in our definition. Instead, the "engineering" is maintaining the overall "structural integrity" of the project. They are in some ways more practical and have a bigger overall view of keeping the project together (see other references of "software developer" vs. "software engineer"). The engineer will make sure that the right tools are used and it will be designed in a maintainable way. Their jobs might also include watching over the product long-term. If you hire a Research Software Person instead of a RSE, they can make something but it might start falling apart after a few years, might not be modifiable, might not use best practices for reproducibility and distribution - basically, the problems in science that RSEs are made to solve. Summary</h3> If you wanted a definition of "Research Software Engineer", we don't have it - but right now, that is probably an impossible task. However, we do hope it has made you think about what it means to you, and appreciate the diversity of the community. If you want to discuss more, why not join the Nordic-RSE community chat</a> and discuss more?

ACM SIG Education</h4>
The ACM SIG HPC education chapter had an informal meeting that we joined out of interest which seems like a nice forum for exchange around HPC education at universities and centers around the world: https://sighpceducation.acm.org/</a></p>

Other accounts to follow to seed your community</h2>
TODO: We should try to get a category in https://fedi.directory/</a> rather than make our own list.</p>

Future</h2>

Please send pull request with updates.</li>
We should contact SocRSE UK and ask them if they are interested in a Mastodon community.</li> </ul>

Challenges in publishing software papers</h2>

Nordic-RSE

International RSE Day 2026!

Nordic RSEs: satisfied, skilled and in demand but looking for clearer career paths

The Finnish RSE meetup 2026

Nordic-RSE friendship book

RSE worldwide session at RSECon25 - taking inspiration back to the Nordics

RSE Meetup in the Helsinki Region – Celebrating International RSE Day!

JOSS re-evaluated as JUFO 1 in Finland, expands its definition

Nordic-RSE conference 2025: Thank you for a great time!

Join Us at Nordic-RSE conference 2025: A Home for Research Software Enthusiasts!

Small steps towards sustainable and open research - or why you should care about Research Software Engineering

Insights from the first Nordic-RSE conference in May 2024

Imp-RSE-sions from SuperComputing conference 2023

State of Research Software Engineers on Mastodon

Summary of the first Finnish RSE meetup

Take the 2021 international RSE survey: help us improve the RSE community

How to be a 'good' git evangelist?

Seminar report: Package Development in Julia

How to get funding for software projects

Research software journals

Unconference 2021

What is 'R'? What is 'S'? What is 'E'?

Nordic-RSE

International RSE Day 2026!

Nordic RSEs: satisfied, skilled and in demand but looking for clearer career paths

Insights from the International RSE Survey 2026</h2> This post shows results from the 5th international RSE survey that ran in early 2026. Over 950 Research Software Engineers from 55 countries shared insights into their career and interests. </p>

The Finnish RSE meetup 2026

Nordic-RSE friendship book

RSE worldwide session at RSECon25 - taking inspiration back to the Nordics

RSE Meetup in the Helsinki Region – Celebrating International RSE Day!

JOSS re-evaluated as JUFO 1 in Finland, expands its definition

Nordic-RSE conference 2025: Thank you for a great time!

What We Talked About</h2> The range of topics was wide and reflected the diversity of interests within the Research (Software) Engineering enthusiasts community in the Nordics. To name just a few:</p>

Thank You</h2> A heartfelt thanks to everyone who made Nordic-RSE 2025 happen:</p> Our code of conduct committee</strong>, Heli and Julia</li> The organizing team</strong>: Matteo, Radovan, Luca, Richard, Jarno, and Samantha</li>

Want to Read More?</h2> Here are a couple of reflections and highlights from others in the community:</p>

Join Us at Nordic-RSE conference 2025: A Home for Research Software Enthusiasts!

What Makes This Conference Different?</h4> Unlike traditional domain-specific conferences, this one is about:</p>

Who Should Attend? (Spoiler: Probably You!)</h4> This conference welcomes anyone interested in research software. You don’t have to be an RSE to join</strong>—just curious and eager to learn! Expect to meet:</p>

Small steps towards sustainable and open research - or why you should care about Research Software Engineering

How can organisations help RSEs?</h4> Many organisations already have people doin RSE work, but the people and the organisation might not be aware of the term RSE. To give those people a sense of belonging and knowing that there is others like them, organisations could:</p>

Insights from the first Nordic-RSE conference in May 2024

Imp-RSE-sions from SuperComputing conference 2023

Democratizing HPC workshop</h3> This was a great workshop and we had the chance to see two outstanding presentations (while unfortunately missing the other presentations in this session when jumping to other sessions and meetings):</p>

State of Research Software Engineers on Mastodon

Summary of the first Finnish RSE meetup

Take the 2021 international RSE survey: help us improve the RSE community

How to be a 'good' git evangelist?

Seminar report: Package Development in Julia

How to get funding for software projects

Part A: Where and how to get funding?</h3> There are some guides about funding of open source software projects:</p>

Research software journals

Advantages of writing a software paper</h3> Citable, citations are researchers currency</li> increases visibility of the software</li>

Why not just Zenodo?</h3> Not recognized by several citations counting tools, e.g. google scholar</li> </ul> Challenges in publishing software papers</h2>

Challenges in publishing software papers</h2>

Some research software journals</h2> Journal of Open Source Software (JOSS)</a> peer reviewed</li> open access</li> no fee</li> </ul> </li>

Unconference 2021

What is 'R'? What is 'S'? What is 'E'?