The Code is Science blog. Guides, policy notes and session archives.
Practical writing on opening, reviewing, archiving and citing research code, plus the original 2017 MozFest notes.
How to organise a research project folder so others can follow it
A research project that only its author can navigate is hard to review, hard to hand over and hard to reproduce. A simple, consistent folder layout fixes most of that, and it takes an afternoon to set up.
Read the guideTeaching researchers to code: what works
Most researchers learn to code by copying a colleague's script and hoping. There are better ways. This guide covers the teaching approaches that have proven themselves in research settings and how to start one where you work.
Why journals should require code
Journals already require data, methods and conflict of interest statements. Code that produces the results is part of the evidence too. Here is the case for asking for it, and how to do it without wrecking anyone's week.
Reproducible environments for research code
Sharing your code is step one. Making sure it still runs on someone else's machine, next year, is step two. The tools are mature. The hard part is choosing the right level of effort.
Funding the maintenance of research software
Research software is easy to fund once and hard to fund forever. This guide explains why maintenance falls through the gaps and walks through the realistic ways to pay for it, from grant budgets to community donations.
Archive your code with a DOI
A GitHub link in a paper is a bet that the repository will still exist, unchanged, years from now. Archiving a release with a DOI removes the bet. It takes about fifteen minutes the first time.
A practical checklist for reviewing research code
You agreed to review a paper and the code came with it. You do not need to audit every line. You need a plan that fits into a few hours and tells the editor something useful.
Research software engineers: who they are and how to work with them
Research software engineers combine research knowledge with software skills. Many groups only call them when something breaks. This guide explains the role and how to bring an RSE in early, when it helps most.
Choosing a license for research code
Public code without a license is not open code. Picking one takes ten minutes once you know the trade offs, and it is the single cheapest thing you can do to make your work reusable.
Running code review inside a research group
Code review is routine in software teams and rare in research labs. It does not need heavy process. A small, regular habit catches errors early and spreads skills across the group.
How to write a code availability statement that actually works
"Code available on request" is not a statement. It is a promise that usually goes unkept. A good code availability statement tells a reader exactly what exists, where it lives and how to use it, in four or five sentences.
Common errors in research code and how to catch them
Most bugs in research code are not exotic. They are the same handful of mistakes, repeated across fields. Knowing what they look like makes them much easier to catch before a reviewer, or a reader, does.
Reproducibility, replicability and code: what the debate means for your scripts
People argue about reproducibility using words that mean different things in different fields. Sorting out the terms makes it clearer what sharing code can fix, and what it cannot.
FAIR principles for research software, explained
FAIR started as a set of principles for data. Software needed its own version, because code changes, depends on other code and gets run, not just read. Here is what FAIR4RS asks for, in plain terms.
Writing a software management plan for a grant
A software management plan says what code a project will produce, how it will be built and shared, and what happens to it when the money ends. It can be a page long and still be useful, to reviewers and to you.
Publishing research software in JOSS: what to expect
The Journal of Open Source Software reviews the software, not a long manuscript about it. The paper is short, the review happens in public on GitHub, and most of the work goes into making the code easy to install, use and trust.
How journals check code: the main models
Journals that care about code do not all check it the same way. Some only ask that it be shared, some ask reviewers to look at it, and some rerun it. Knowing which model you face changes how you prepare.
How to cite software in a paper
If a result depends on a piece of software, the paper should say which software, which version and who made it. A software citation does that in one line, and it takes less effort than most people expect.
Making Jupyter notebooks reproducible
Notebooks are great for exploring and explaining results, and easy to break without noticing. A few habits make sure a notebook run top to bottom in a fresh kernel gives the results you report.
How to write a README for research code
A README is the first thing a reviewer or reuser opens, and often the last if it is vague. An hour spent on eight short sections makes your research code something others can actually run and check.
Testing research code: where to start
You already check your results by hand. Automated tests do the same checks every time the code changes, so a quiet bug gets caught the same day instead of in review.
Version control for researchers: a practical Git starting guide
You do not need all of Git to do research well. You need a small, steady workflow that records what your code looked like when it produced each result, and keeps data and secrets out.
Good practices and good quality code
You do not need to become a software engineer to write research code other people can trust. You need a handful of habits, a few good references, and a place to put the code when the paper is done.
MozFest 2017 session notes: why research code stays closed
About twenty people, roughly half researchers and half developers, spent an hour listing why research code stays private and arguing about how it could be reviewed. Here is what they said.
MozFest 2017: why is research code not open?
In autumn 2017 the original Code is Science volunteers ran an interactive session at MozFest in London. The question was simple: why is so much research code closed and unreviewed, and what would it take to change that?