How to get started

There are multiple ways your team can get started with these seminars. Each requires you to reflect on your current needs and practices and discuss them to find shared interests. We believe that finding these should not be hard because we all do computational work, and your team has some unifying theme. Below, we list three options that can help you.

Option #1

Start with a kick-off meeting much like a standard brainstorming session: everyone writes down 3-5 software-related questions they have in mind, issues they encountered recently, or technologies they are learning or wish to learn more about. Based on our experience, getting bioinformaticians to complain about software solutions is not hard. There are the all-time favorites of “empty output but no error message,” “it asks for bed format, but complains about chromosome naming and missing columns,” and “it took forever to install, and now R crashed.” After 5-10 minutes of individual time, you can compare your lists, find common themes and prioritize them. This list will be the basis of your upcoming meetings. For example, if many people have installation issues, you can add a session about dependency managers. Learning about data structures and algorithms or user experience might be the most important thing if you develop new tools. If someone learns about Nextflow, while most other people use Snakemake, it is a good idea to share the new information and discuss the pros and cons of each.

The general idea is that you all should be (and probably are) learning new technologies and have ongoing tasks that require (modern) solutions. Once you have a core community (and as early as possible), we strongly recommend looking into basic computer science concepts, such as functions or memory usage. It brings tremendous benefits to know about the layers below you, the basic ideas that build up all the software that you rely on.

Option #2

You may start with a round table on your team's computational background. Questions to answer are:

1. if one has formal education in computer science or software engineering
2. the language they know the best and others they might be somewhat familiar with
3. if one understands how functions and objects work

It is nearly impossible to write decent code without understanding functions, so it is a good idea to bring everyone up to a basic shared understanding of how to properly organize the code. You can find resources for this under (Modularization). It is also a great idea to read a book, such as (Clean Code) or (The Pragmatic Programmer), and discuss the content together with a particular focus on how it applies to your context.

The meetings are viable if there is reciprocity and rotation in who is taking charge of the meeting. No one is happy about unpaid teaching duty, but learning together benefits everyone. You can invite external speakers if there is an informatics department nearby. However, we found it quite beneficial to prepare for topics you might not yet know: preparing to present them is an excellent way to deepen your understanding.

Option #3

Your group may start with weekly code reviews. They are very flexible, informal meetings that require the least effort to establish but have significant benefits in building a community of professionals. Someone showing their code can raise more complex technical questions (e.g., how to package a Python code) that can be discussed later in a dedicated meeting.

Post Tags experience