US-RSE Summer 2026 Newsletter

☀️Summer is in full swing, which means US-RSE is right around the corner...☀️

newsletter August

Published: Aug 5, 2026 by Tinashe M. Tapera (Author & Editor), Sandra Gesing (Editor), Ian Cosden (Editor)

Hi all, it’s been a minute!

Welcome to the Summer 2026 edition of the US-RSE newsletter! In this issue, we are packing in several updates and highlights from the community, and gearing up for USRSE26! Read on for all the latest updates, including upcoming events, recent accomplishments, and opportunities to get involved in the RSE community.

Most importantly, get excited — the conference is just around the corner!

So grab a beverage and settle in as we recap all kinds of updates from the summer! In this issue…

A conference hall full of people

🤔 Arrestive Curiosity & RSEs: Turning Shiny Toy Syndrome into a Feature 🤔

This summer I met some fellow R users at the Boston R User Group meetup, where I finally felt safe saying, “R is the best at [X],” without starting a flame war. Of course, most of us know these debates are rarely about which tool is objectively best. Rather, they’re about which tool is best for a person, a project, or a team.

Which sounds liberating, until it raises a harder question: when should you switch tools?

Technology is full of shiny promises, current LLM trends notwithstanding. New tools are constantly clamouring for our attention, claiming they will solve the frustrations of the old ones, and it is hard to know when experimentation with the new is wise and when it is just distraction.

Ignore new tools completely, and you may miss something genuinely useful. Chase every new one, and you lose days to tinkering.

For RSEs, this tension might just be part of the territory. Many of us are helping scientific teams navigate changing cutting edge questions, which means we are constantly judging whether experimentation with cutting edge tools is worth the cost. That can make “shiny toy syndrome” feel like a liability, at first.

But I think there is a more useful way to frame it: as arrestive curiosity.

By that I mean the kind of curiosity that stops you in your tracks until you can decide whether a new tool is actually better than the one you already have. It can absolutely become a time sink — but it can also be a professional strength, if you give it some structure.

Here are four questions I constantly reference in order to keep my curiosity productive:

  1. What problem am I actually trying to solve?
    Before investigating a new tool, write down the need as clearly as possible. Often the exercise reveals that the current workflow only needs a small adjustment, not a new platform.

  2. How costly is the current pain?
    If the problem is real, measure it. How much time, energy, or team morale is it costing? If the discomfort is tolerable, a switch may not be worth it.

  3. Refine to absurdum. If you are still convinced that something is missing, then it is time to start looking for what is missing. Surely someone has felt this acute pain, right? The internet is a vast place, and there are several billion of us using it at any given time. It’s more than likely that someone, somewhere, has been in the exact position you’re in, with an install that is too slow, a link that doesn’t work, or a workflow that is too clunky and just missing that, secret something. Go out into dark corners of the second, third, and fourth pages of Google search, ask around on Reddit and Facebook groups, or find forums and communities that are relevant to the problem space. Surely someone has faced this problem, too?

  4. If the solution is identified, use it. If not, build it. By this point, if you have found a niche problem that 1) arrests your productivity, 2) causes measurable discomfort, and 3) has not been solved by anyone else, then this is a problem worth solving. In fact, as an RSE, this is the perfect problem to have, because it is within this narrow gap between your vision and the status quo that you can actually make valuable impact to your team. If you can’t or don’t want to build the solution yourself, one of two things must be true: either the problem is not worth solving, or you are not yet the right person to solve it.

In my experience, the really interesting Research Software Engineering is what happens when as an engineer I have become obsessed with a particular technological blocker to the success of my or my colleagues’ scientific endeavors.

It is the moment we look at the scientific engine and say, “I know we could just use [X Tool] to write this part of the paper, but I just can’t accept that this is the best way to do it. I simply can’t. There must be a better way.”

This is the “arrestive,” part of “arrestive curiosity” — the part that keeps you up at night, ceases you in your tracks every time you think about it, and continues to consume all of your mental energy until you have either found a solution or come to terms with the fact that there is no solution.

And if you ask me, that tendency to be obsessed with finding the best way to do science is what makes a good RSE a great RSE. So, the next time you find yourself in the throes of shiny toy syndrome, try to channel that energy into arrestive curiosity using the flowchart I outlined above, and see where it takes you. You might just find that the perfect tool was right in front of you all along, or you might end up building something that changes the game for you, your team, and perhaps even the science itself.

📣 Mark Your Calendars for USRSE’26! 📣

Save the date for USRSE’26: Advancing Science in the Age of AI

USRSE'26 Conference Logo

USRSE’26, to be held at the San Jose Marriott from October 19-21, 2026 in San Jose, California, with the theme “Advancing Science in the Age of AI”, is ALMOST HERE!

Chairs have been appointed to lead each of the core committees for USRSE’26. These chairs have begun assembling sub‑teams from the pool of volunteers who expressed interest in supporting the respective areas. If you were not selected for a chair position, please stay tuned, as chairs may reach out for volunteers for these committee positions.

What’s next?

  • Call for Proposals: Submit your work via papers, short talks, BoFs, workshops, or posters. View More
  • Call for Reviewers: Play a key role in creating a dynamic and varied technical program that will appeal to conference attendees from all RSE backgrounds. Apply to Review
  • Committee Formation: Sub‑teams will be formed shortly; be on the lookout for an email from a perspective committee chair with details.
  • Stay Informed: Regular updates will be posted at us-rse.org/usrse26. Please bookmark the page and check back frequently for the latest information.

Your continued involvement is essential to the success of USRSE’26. We look forward to collaborating with you to deliver a vibrant, inclusive, and impactful conference.

📧 Join Our Mailing List 📧

Want to stay updated on all things US-RSE? Join our mailing list to receive direct news about all US-RSE conferences. Sign up here.

💬 Have Questions? 💬

If you have any questions, feel free to reach out to the organizers at usrse26-conference@us-rse.org.

📅 Save the Date 📅

Travel information, including hotel details and travel tips, are available. Stay informed at us-rse.org/usrse26!

We’re looking forward to seeing you all in San Jose very, very soon!

🗞️ Community News 🗞️

The Whole Person: Pride and Belonging in US-RSE

Pride Month is both a celebration and a moment for reflection for the communities we are part of. As the chairs of the DEI Working Group, we welcome everyone to celebrate Pride Month with the US‑RSE community this June and beyond. We also want to take a moment to reflect on what Pride means to me and how it shapes how we think about belonging in our professional communities.

US‑RSE is a community built around shared skills, interests, and goals centered on advancing research through software engineering. While that core set of interests brings us together, we are also a collection of individuals who work across different research domains and parts of the software engineering lifecycle. Each person brings unique strengths and perspectives.

A mix of viewpoints helps teams generate stronger ideas and advance research. That kind of collaboration works best when people feel a sense of belonging.

At the same time, we don’t show up to these communities as just “RSEs.” Each of us brings life experiences, preferences, and unique quirks. You can’t interact with just the “software engineer” side of someone. You interact with the whole person, which means accepting them as they are.

That’s where belonging comes from. It’s not just about being part of a group with shared interests. It’s about being accepted as you are.Creating that kind of belonging can be challenging in practice, especially when building trust with people who have experienced bias, exclusion, or worse.

That’s why small actions matter. Sharing pronouns, using gender‑neutral language, and taking the time to learn about the people around us can make a real difference. They signal that people are seen, respected, and welcome as part of the community.

For us, Pride is a reminder that this kind of belonging does not happen by accident. It is something we create together through everyday choices.

Pride means different things to different people. To reflect that range of experiences, we invite members of the US‑RSE community to share what Pride means to them and how they think about belonging in their work.

What does Pride mean to you? We’d love to hear your perspective. Feel free to join the conversation on Slack or share on social media using the hashtag #RSEPride.

Community Contributions

Research software often involves intensely multidisciplinary collaboration, and, depending on the size of a team, may require the ability to liaise between domains, technical-side, business-side, etc. and advocate whether it’s for data integrity processes or for underweighted voices. In my mind this relational communication and openness is very prosocial and qualitatively close to what Pride is all about; I think it’s why I feel at home in research software and the surrounding communities. – Michael P. Pascale

I actually did not grow up playing with computers. I always was tech savvy, but never imagined myself opening a terminal or writing code. So when I found myself engaging with technology in research, I was very intimidated, often suffixing all of my conversations with, “but I don’t know anything about this stuff.” That feeling of imposter syndrome went away when I joined the RSE community, and I owe my career success to the culture of support and encouragement that I found here. Celebrating Pride Month with the LGBTQ+ community every year is a reminder of how unconditional acceptance and support enables people to self-actualize and thrive. I stand with my LGBTQ+ allies in celebrating them and advocating for their space in our world! - Tinashe M. Tapera

Community Shoutouts

🥳 Congratulations to members of the RSE community recognized with Stanford Data Science (CORES) awards!

  • Malcolm Barrett & Alex Koufos : OpenSource@Stanford Community Prize
  • Ellianna Abrahams: Open Science Innovator Prize

These awards recognize individuals who have made significant contributions to open science and data science, and we’re thrilled to see members of our community being honored for their impactful work!

Additionally, The RAPTOR team from Argonne National Laboratory and collaborating institutions recently won the SC25 Best Reproducibility Advancement Award, using Chameleon Cloud to make their artifact fully reproducible. This marks the second consecutive year a Chameleon user has taken home this honor!

Read the announcement here.

Did you know that we have a community Code of Conduct? Anyone is able to view it in the #code_of_conduct Slack channel, under Files!

In Memoriam

We mourn the loss of a dear friend and colleague, Cleve Moler, who passed away on May 20, 2026, at the age of 86 at his home surrounded by his family. Cleve was chief mathematician and cofounder of MathWorks and the author of the first version of MATLAB. Please join us in remembering their contributions to science and engineering by reading Mathworks official announcement here.

Community Spotlight

🌱 Our community is full of people doing fascinating research and software work, and we want to put a face to it. Starting this month, we’ll be featuring a group of different members in a regular spotlight: what they work on, a tool they can’t live without, and how they found their way into RSE work.

We’d love to feature YOU. It takes about 5 minutes to fill out, and nothing gets posted without your okay: https://forms.gle/dXqVsHKiHnot2u449

Email Pengyin Shan for any questions!

Community Calls

Our next meeting is scheduled for Thursday, July 9, 2026, 12:00PM EST. We hope to see you there!

👀 Interesting Events and Opportunities 👀

Have an event or opportunity you want to promote? Reach out on Slack in the #newsletters channel!

📚 Featured Reads, Videos, and Podcasts 📚

📑 Recent Publications

  • Macdonald, A., Baker, C., To, I.et al.. STAMPED principles for reproducible research objects. f3h82_v1. Read it.

📇 Blog Posts & Other Reads

  • Labs, S.. CrankGPT — Local Human-powered AI. Check it out.

  • Whittaker, Z.. Dozens of America’s largest companies have no simple way to report security flaws. Check it out.

  • International Mathematical Union. Leiden Declaration on Artificial Intelligence and Mathematics. Check it out.

  • Reading, T.. The Real Scoreline reveals nations facing climate penalties - University of Reading. Check it out.

  • Schreiner, H.. Claude Code Reviews with Fable. Check it out.

  • Udell, J.. How to make best use of git and GitHub for AI-assisted software development. Check it out.

🎧 Podcast Episodes, Videos, and More

  • . BioChem-ready Slurm Cluster in minutes — Clusterra Walkthrough. Watch here.

  • Schmidt, P.. [EN] Does Spec-Driven Development replace agile? With Graham Lee - Code for Thought. Listen here.

  • Schmidt, P.. [EN] What happened to agile development? - A review with Dave Thomas - Code for Thought. Listen here.

  • Schmidt, P.. [EN] When Bits Rot - with C McKean, L Talboom, A Page-Mitchell - Code for Thought. Listen here.

Did you read something interesting this week? Want to share your own publications in the community? Reach out on Slack in the #newsletters channel!

🏃 Get Involved! 🏃

US-RSE Working Groups:

🧑‍💼 Recent Job Postings 🧑‍💼

Other Job Boards

You can learn more about job boards in the #jobs Slack channel!

This newsletter is a joint effort of members of the US-RSE Association.

© US-RSE • 2021–2026 • US-RSE is a fiscally sponsored project of Community Initiatives

Email Mastodon Twitter YouTube LinkedIn GitHub

Share

⬆️ Back to top ⬆️