Last fall we got a bunch of students, postdocs, research assistants and faculty together to have a meeting every two weeks. We talk about software that may be useful for everyone’s research, or discuss coding problems that one or more of us may have encountered. It’s been working really well, so I got approached by the Mozilla Science Lab crew who asked whether I wanted to talk about how we run these meetings during the monthly community call. I thought maybe a blog post might help to give a bit more advice in case you missed the community call. So here we go, steps toward starting a successful software workout group:
1. Commitment: You need at least a few people who are committed to this. That doesn’t mean that everyone needs to show up every single time, but it takes a core group of people to keep pushing and to keep the meetings alive. Set a fixed time, book a room, and make sure to…
2. …plan ahead for a few weeks: We meet a the beginning of the term to make a schedule for the entire semester. We assign topics and speakers, so everybody can put those dates in their schedule. That way you avoid cancelling a meeting because you can’t find a speaker or topic at short notice.
3. Get rid of hierarchies: The topics we talk about all come from within the group. If somebody knows a good software and thinks it might help people with their research – they add it to the list. If somebody would like to learn about a particular command or software – they add it to the list. Everything is driven by the group, not an organizer or teacher. Similarly, all our speakers otherwise sit in the meetings as students. Everybody is in the same boat. Peer-to-peer teaching really works!
4. Stop believing that you have to be a software expert: I was in the same trap in the beginning. I never would have thought that I had something to contribute to a software workout. After all I’m a scientist, not a programmer! But turns out when we’re all scientists in the room that doesn’t matter anymore. I may not know everything about a particular command or programming language from a professional point of view. But I do know how to use it for my scientific purposes, whereas other people in the group may not even realize that it exists. Even more importantly, I can put the commands into a scientific context where everyone else can understand what I’m talking about and can imagine how it may be useful for them. So just believe in yourself and your abilities!
Our meetings started with a group of people who all attended a Software Carpentry bootcamp. Whereas I don’t think this part is crucial it was a nice way to kick start our biweekly meetings: We already had a group of people from different disciplines in one room, and everybody was interested in learning how to deal with their day-to-day data processing more efficiently.
In general it doesn’t matter what topics your group choose or which language you prefer to code in. In our meetings we use a combination of shell scripting, Python, and Matlab. We add on tools and software as needed.
Lastly, I just want to put in a quick word about interdisciplinarity. It’s really a blessing and a curse. In some ways, because we all come from different disciplines, sometimes a particular topic won’t appeal to everybody. That’s fine. If the schedule is known ahead of time, everyone can make a decision whether they want to take this opportunity to learn something new, or maybe skip the meeting and focus on other work. On the other hand, many disciplines have certain software that are “standard”, where knowledge about usage gets passed on from one generation of researchers to the next. However, sometimes it can be great to get a new perspective on things. Even within our Earth Sciences department, sometimes the oceanographers might use a tool that could be useful for seismologists that they don’t know about, and vice versa.
That leaves only one thing: Let the software workouts begin!