Conferences are part of RSE life, but nobody really tells you how to do them. Which conference should you go to? What counts as something worth submitting? How many slides do you need? What are you supposed to do when someone stands in front of your poster and stares at it silently?

After attending and presenting at quite a few conferences, I've accumulated some opinions and practical rules. Nothing here is profound. It's mostly stuff I wish someone had told me earlier.

First, pick the right conference

Start with what you actually want out of it. Do you want to present your work, learn a technology, meet other RSEs, find collaborators, or get closer to the research community your software serves?

For RSEs, I think conferences roughly fall into a few buckets. There are domain conferences, like AGU for Earth and space science; research computing conferences, especially PEARC; RSE conferences, like US-RSE; and technology conferences, like KubeCon or AWS re:Invent. My original talk also included examples from specific research communities such as geoinformatics and sustainability.

A few good starting points:

  • US-RSE Conference: probably the most directly relevant if you want to meet other RSEs and talk about the profession itself.
  • PEARC: research computing, cyberinfrastructure, research software, HPC, data, workforce, and related topics.
  • SC (Supercomputing Conference): HPC, supercomputing, research computing, scientific software, large-scale systems, and emerging computing technologies.
  • Gateways: science gateways and research software that connects researchers with computational and data resources.
  • AGU Annual Meeting: a huge domain conference if your work touches Earth, environmental, climate, atmospheric, or geoscience research.
  • IEEE eScience: computational and data-intensive research, scientific workflows, research infrastructure, and eScience.
  • KubeCon + CloudNativeCon: useful when the technical side of your RSE work is the point: Kubernetes, cloud-native infrastructure, DevOps, observability, and so on.
  • AWS re:Invent: enormous and very industry-oriented, but useful for cloud architecture and hands-on technical learning.

Ask your coworkers where they go too. People doing similar work are often the best conference recommendation engine. I also like looking through the previous year's program. If you keep seeing talks you wish you had attended, or can easily imagine your own work fitting there, that's usually a good sign.

Actually read the call for submissions

I mean actually read it. Not just the conference name and the big SUBMIT button.

Before writing anything, check the deadline, the tracks, what formats they accept, and what each format requires. A conference might accept full papers, short papers, presentation-only abstracts, posters, tutorials, workshops, panels, or BoFs (Birds of a Feather, basically an informal session organized around a shared topic). The requirements can be surprisingly different even within the same conference.

These things sound painfully obvious until you get one wrong. I once wrote an abstract for eScience and then realized, after the weekend, that I had forgotten to check the actual date and had missed the submission deadline entirely. The abstract was ready. The conference was not waiting for me.

So now I work backward from the deadline and leave some time for coauthors, PIs, or project leads to review things. Also, assume the deadline is real. Sometimes conferences extend them, but gambling on that is not a submission strategy lol.

You probably have something worth submitting

I think RSEs sometimes underestimate this because we compare ourselves with researchers presenting a shiny new scientific result.

A useful RSE submission can be a framework you built, an interesting use case, a technical problem you solved, lessons from deploying something, a comparison of tools, or a development practice that worked particularly well.

The better question is simply: would someone in this audience find this useful?

If the work belongs to a research project, talk to the PI or project lead before you submit it. Figure out whether the project actually wants the work presented, who should be an author, and what order the authors should appear in. These are much nicer conversations three weeks before the deadline than three hours before it.

Then try to tell a story. "We built X using Y" is usually less interesting than "we had this problem, tried this approach, discovered these things, and here's what might be useful to you."

My slide rule: X minutes, X−2 slides

My completely unscientific rule is X minutes, X−2 slides. Twenty-minute talk? I start around 18. Ten minutes? Around eight. Obviously some slides take ten seconds and some take three minutes, so don't take the formula too seriously. The point is to leave yourself room.

If you're running over time, don't solve the problem by talking faster. Skip something. Nobody has ever sat through a conference talk thinking, I really wish this person had squeezed in another architecture diagram.

Practice once with a timer. You don't need to memorize the presentation, but you should know whether your 20-minute talk is secretly a 37-minute talk.

And on the day, get there early enough to make sure your laptop, slides, adapter, videos, fonts, animation, and whatever other clever thing you put in the presentation actually work.

Posters need a pitch

Poster sessions felt weird to me until I realized the poster isn't really the presentation. You are.

Have a one- or two-minute version ready. Someone walks up, you give them the basic problem, what you did, and why it matters. If they're interested, you keep going. If they aren't, everyone gets to escape gracefully.

Also, don't let people ninja past you while pretending not to make eye contact. Say Hi. Ask whether they're familiar with the topic. Give them an easy opening.

Make the poster visual, and put a QR code somewhere obvious that points to the project, paper, demo, GitHub repository, or whatever you want people to remember afterward.

Start the logistics stuff early

Once you know you're going, register and start the travel process. Learn your institution's reimbursement rules before spending money, book the hotel before the conference block disappears, and keep the receipts. For international conferences, check travel authorization, insurance, and whatever institutional paperwork applies before you leave.

Before the trip, I look through the program and save the sessions I actually care about rather than trying to make those decisions every morning. Check the weather. Bring whatever adapters you need. And pack your charger. Seriously. Chargers may be the natural predator of conference attendees. People either forget them or mysteriously lose them.

As for dress code, I find photos from previous years much more useful than trying to decipher "business casual." Engineering conferences in particular are pretty relaxed these days. Jeans are generally fine, and a T-shirt with your university, lab, project, or company logo isn't unusual.

I personally still draw the line at sandals. Some standards must survive.

Don't optimize the conference too much

It's very tempting to open the schedule and construct the perfect itinerary from 8 a.m. until 5 p.m.

I don't anymore.

Some of the most useful parts of conferences happen between the scheduled things: talking to someone after their presentation, finding another group using the same software, getting introduced to somebody whose paper you've read, or sitting down for coffee and discovering that two projects have basically been solving the same problem independently.

My original roundtable talk ended with networking, committee opportunities, and sharing stories with other attendees. Years later, I think I would emphasize that part even more.

Go to talks, obviously. Learn things. Present your work. But leave some empty space.

And when everything is over, go out with your coworkers and collaborators. Meet people. Have dinner. Have a drink if that's your thing. If there's an open bar, well, don't be shy. :-)

My very short checklist

Before submitting: right conference → right track → right format → PI and coauthors aligned → requirements checked → check the date again → submit.

Before presenting: cut the slides → practice with a timer → prepare the short version → add a QR code if useful → test everything on site.

Before traveling: register → book → check reimbursement and travel policies → save receipts → check weather → pick a few sessions → PACK YOUR CHARGER.