Science communication is a skill that needs to be taught

Software engineering researchers spend a lot of time and effort on studying how software is (or should be) developed. Every once in a while they publish their findings in a scientific paper. Any recommendations that are made are then picked up by software developers and other stakeholders to improve their craft, which is how the world becomes a better place – at least in theory.

In practice, discoveries made by software engineering researchers rarely “trickle down” to the people that need them the most, because few developers have the means to attend live scientific conferences and papers have to compete with other types of content that are easier to discover or consume (side note: Not to mention more entertaining…).

As a result, almost no one reads papers or is even aware of scientific discoveries. I guess this would explain partially why so many people I’ve worked with waste time on endless bikeshedding and reinventing the wheel for common problems even though answers and effective solutions already exist. 😒

Software engineering scientists clearly need to get better at communicating their work – not just to their peers, but also to the general public. Doing so would increase their impact and visibility as a scientist or engineer. Universities should therefore equip their students with the necessary skills to communicate scientific work effectively, preferably as early as possible.

And that’s exactly what the authors of this paper did: they created a science communication course for computer science bachelor students. This week’s paper discusses their experiences and the lessons that were learnt from the first run of that course.

The science communication course was designed as a six-month seminar, in which students have to think of and implement (preferably creative) ways to effectively communicate the contents of a paper to one or more target audiences.

The course should achieve two learning objectives. Firstly, students get more acquainted with the scientific process and working with scientific literature. Secondly, students are required to reflect on and experiment with communicating scientific software engineering findings.

The seminar started with a kick-off meeting, in which students and the instructor shared their expectations about the seminar and exchanged examples of good science communication with each other.

In the three weeks that followed, students were assigned to a paper. Prior to the start of the course, the instructor had pre-selected a set of ten already published software engineering papers of comparable length that require little prior knowledge to understand. Students were asked to choose for each paper whether they considered it to be in their “Top 3”, whether it “Would be okay” for them or whether they would “Rather not” be assigned to the paper. These preferences were then taken into account for the paper assignment.

Once each student was assigned to a paper, they had three weeks to prepare a short lightning talk in which they had to draw attention to the paper and could focus on certain aspects of the paper. The time limit was deliberately set to two minutes, so that presenters were unable to describe the paper in detail. This inevitably led to questions from the audience, which helped the presenter understand what the audience wanted to know more about.

The main deliverable for the course was a portfolio, consisting of a report about the assigned paper and a collection of developed and well-founded ideas for communicating the contents of the assigned paper. Examples include (but are not limited to) videos, social media stories, blogs, news articles, workshop concepts, nad posters.

Students were given the opportunity to schedule an informal 1-on-1 meeting with the instructor to discuss ideas and their progress on the portfolio. Moreover, an informal group meeting was held with all students six weeks after the lightning talks to discuss questions and uncertainties.

For the final presentations, students were granted 15 minutes on stage to present the communication strategy that they had developed. Ideally, parts of the strategy could also be used to present the contents of the paper.

Eight students registered for the seminar, of which seven successfully completed (side note: One student dropped out of the programme halfway through the semester, presumably for unrelated reasons.) and participated in an evaluation of the course. The course was received quite positively, with four out of seven students indicating that participation in the seminar had increased their interest in science communication.

For instructors who wish to implement their own science communication course, the paper mentions four major takeaways (side note: The original article describes the course design, caveats, and considerations in way more detail. It also provides a few examples of students’ coursework.):

There were four major takeaways in particular:

• Students appreciated that they were given sufficient time to familiarise themselves with a paper of their choice, as this made it easier for them to focus on science communication instead of having to struggle with the contents of the paper.

• The high levels of creativity involved in the course were praised by students, but at the same time students felt that expectations about the portfolio size were unclear (side note: e.g. how many pages is enough?), and one student had wished for more reading material about science communication.

• In order for the seminar to work well, it has to be a safe place for everyone. The instructor is responsible for creating an environment where students can safely provide and receive constructive feedback from each other.

• A course like this one could also be implemented for other disciplines and universities, albeit with some small modifications. Alternatively, science communication lessons could be integrated into existing courses.