Coding Clubs For Research Software Communities: Questions to Consider (Part Two)
Coding Clubs For Research Software Communities: Questions to Consider (Part Two)
Posted on 13 July 2021
Coding Clubs For Research Software Communities: Questions to Consider (Part Two)
Photo by Lagos Techie on Unsplash
By Matthew Bluteau, Sarah Jaffa, Colin Sauze, Sam Haynes and Callum Rollo.
This blog post is part of our Collaborations Workshop 2021 speed blog series.
This is part two of two blog posts. See the first part.
How Will You Sustain the Community?
Code of Conduct
It is important to show you take inclusion seriously. Add a Code of Conduct file to your club website, and start meetings by outlining key points in the CoC. The Carpentries Code of Conduct is a great place to start, and you can use it as a template as long as you attribute it.
Combat negative ideas
- “I can’t really code, I just copy from Stack Exchange.”
Adapting code is a crucial part of coding! There is no need to re-invent the wheel, the task of incorporating other people’s code into your own is a skill! It very rarely works the first time and debugging forces you to learn what is going on under the hood. That being said, make sure you give plenty of credit to those who you’ve copied code from.
- “I don’t want my peers/supervisors to judge me on my code.”
Establish a positive environment around failure. If there is a mistake in your code, it’s a bit scruffy or there is a simpler way of completing the task, then this is a great route to find answers! Keep in mind senior academics aren’t necessarily better programmers because software engineering in research is still fairly rare and novel. If you hold a more senior position, use your influence to build an environment where everyone feels safe to share their code, perhaps by sharing yours first and actively pointing out places that you think need improvement.
Maintain Presence
Pick a social media platform relevant to your club to regularly post on, preferably at least once a week. It’s not only great advertisement but it also shows your events are still running which encourages new users to join. The key to maintaining a presence is to think ahead! Consider preparing advertisement posts a week or more in advance so that they can easily be posted if things get busy closer to the event.
Open Debate
Be as open as possible. If you are debating the format or topic of the next meeting open a GitHub issue and allow people to see the discussion and to comment. Don’t just make the decision at the previous meeting because then new people can’t get involved!
Continuous Integration
A great way to maintain interest is to encourage attendees to contribute to your sessions/tutorials/resources. Whether its providing a model answer, writing question/problems, or running a session themselves. They do need support to do this! Creating a README file with a section on contributions would help, also offering to check slides/resources/answers can help, or possibly even offering to co-run the session.
Resources
- Rosalind: bioinformatics inspired problems, you download the input data and upload your output for verification.
- Advent of Code: a Christmas-themed daily challenge that follows a similar format to Rosalind.
- Project Euler: for more generic mathematical problems.
- Coding Dojo Handbook: book that details how to run a Coding Dojo.
- Coding Dojo Website: a variety of free resources for running a Coding Dojo, including coding problems.
- A repository of “katas”, i.e. coding problems: there are some refactoring problems here too.
- CodeChef: multi-language mathsy code problems.
- Coder Dojo: for teaching kids to code.
- Kaggle: machine learning oriented tutorials, challenges and data sets.
- Edinburgh University R coding club.
- Aberystwyth Python Study Group.
- R Ladies.