Teaching researchers to code: what works

Ask a room of researchers how they learned to program and most will say they picked it up. A supervisor handed over a script. A tutorial online got them halfway. A colleague fixed the error message at the last minute before a deadline. That works, up to a point. It also produces code that nobody else can read and habits that are hard to unlearn.

Teaching researchers to code is a different problem from teaching computer science students. Researchers are busy, they already have expertise in their own field, and they want to solve a specific problem next week. The approaches that work take those facts seriously. This post covers the ones with the strongest track record.

What makes researchers different as learners?

They are adults with a goal, limited time and plenty of domain knowledge. That changes almost everything about how teaching should be designed.

• They want relevance. Abstract exercises about sorting lists feel like a waste of time. Cleaning a messy spreadsheet does not.
• They learn in fragments. Teaching often happens around fieldwork, lab schedules and teaching duties, so long courses lose people.
• They fear looking foolish. Senior researchers in particular can be reluctant to admit they do not know something basic.
• They bring very different starting points. One workshop can include someone who has never opened a terminal and someone who has written a thousand lines of R.

Good research coding instruction is designed around these constraints rather than against them.

What is The Carpentries model?

The Carpentries is a nonprofit that teaches foundational coding and data skills to researchers, mostly through short, intensive workshops. It brings together Software Carpentry, Data Carpentry and Library Carpentry, each with lessons aimed at a slightly different audience. It is the most widely used model for this kind of teaching, and many local programmes borrow from it even when they are not official Carpentries workshops.

A few features make the model work:

1. Short and intensive. A typical workshop runs over two days, or the equivalent spread across several half days.
2. Practical core skills. Common topics include the Unix shell, version control with Git, and programming in Python or R, often using a real research dataset.
3. Open lessons. Lesson materials are openly licensed and developed collaboratively, so anyone can read, reuse and improve them.
4. Trained instructors. Instructors complete training in teaching practice, not just in the technical content, and often volunteer.
5. Helpers in the room. Extra people circulate to unblock learners, so one broken install does not stall the whole class.

Many institutions join as members, which lets them train their own instructors and run workshops regularly.

Why does live coding work so well?

Because learners see the process, not just the result. In live coding the instructor types code in front of the room, step by step, and learners type along. It is slower than showing finished slides, and that is the point.

Live coding shows how a real programmer works. They make typos, read error messages and fix them, check the documentation and try again. Learners discover that errors are normal rather than a sign they are bad at this. The pace also stays human. When the instructor has to type every line, they cannot rush through ten concepts in a minute.

A few practical habits help:

• Use a large font and a plain, high contrast theme.
• Say out loud what you are about to type and why.
• Leave mistakes in and fix them visibly.
• Stop every ten or fifteen minutes for a short exercise.

How do you know whether people are keeping up?

Ask often, and make it easy to answer. One well-known technique is to give each learner two coloured sticky notes. A green note on the laptop means "I'm done" and a red one means "I need help". Helpers can see at a glance who is stuck, and learners can ask without interrupting.

Short exercises do the same job. A two minute task after each concept shows the instructor whether the room understood or whether to explain it a different way. At the end of each session, ask learners to write one thing that went well and one thing that could be better. Read them before the next session and adjust. Small, frequent feedback beats a long survey at the end.

What are hacky hours?

Hacky hours are regular, informal drop-in sessions where researchers bring their own code problems and work on them alongside others. They are usually weekly or fortnightly, often in a cafe or a common room, and anyone can come.

A workshop teaches the basics. A hacky hour is where people apply them to their actual research. Someone brings a script that will not run on the cluster. Someone else wants a second opinion on how to structure a project. A third person just wants a quiet hour to work with help nearby.

They are cheap to run. All you need is a regular time, a room, and one or two people willing to answer questions. The most important factor is consistency. A session that happens every week at the same time builds trust in a way that occasional events do not.

How does peer learning fit in?

Peer learning turns learners into teachers, which deepens their own understanding and spreads the work. Study groups, reading groups for code and pair programming between colleagues all fall into this category.

A study group might meet monthly, with a different member presenting a tool or technique each time. A code review club might look at one short piece of real research code each session and discuss how to improve it. Our post on code review in research groups describes how to set one up without making it feel like an exam.

Peer learning also helps with the confidence problem. Asking a colleague at your own level feels less risky than asking an expert, and explaining something to a peer is one of the fastest ways to discover the gaps in your own knowledge.

How do you build a local community that lasts?

Combine formal and informal formats, and make it someone's recognised job. Programmes that last usually have three layers:

Layer	Format	Purpose
Entry	Workshops, two days or equivalent	Foundational skills and confidence
Practice	Hacky hours, drop-in help	Apply skills to real research problems
Depth	Study groups, code review clubs, advanced lessons	Ongoing learning and peer support

Recruit instructors from past learners. People who recently learned something often explain it better than experts. Work with the library, the research computing service and any local research software engineers, who often have both the skills and the motivation. And keep a shared chat channel or mailing list so people can ask questions between sessions.

Finally, make it visible. Count attendance, collect short stories of what people did with their new skills, and share them with department heads. A volunteer effort survives much longer when the institution sees its value.

What should a first lesson cover?

Something useful by the end of the day. Good first topics are those that save time immediately: automating a repetitive file task with the shell, reading and plotting a dataset, or putting a project under version control. Notebook tools such as Jupyter can lower the barrier at the start, as long as learners also see how to turn their work into reusable scripts later.

Avoid trying to cover everything. Three ideas that stick are worth more than ten that blur together.

Setup deserves its own attention. Installation problems are the most common reason a first session goes badly. Send clear setup instructions a week ahead, offer a short install clinic the day before, and keep a cloud or browser-based fallback ready for anyone whose laptop refuses to cooperate. Learners who spend the first hour fighting an installer rarely recover their enthusiasm. Once the first lesson is done, point people to the next step, whether that is a hacky hour, a follow-up workshop or a short guide such as good practices for research code.

What to do this week

Find out whether your institution is a Carpentries member or already runs workshops, and pass the details to your group. If nothing exists, book a room for a one hour drop-in session at the same time each week for the next month and invite your department. Bring one example problem of your own in case nobody else does. It is a small start, and most lasting local communities began with exactly that.