How we aspire to work:
the lab principles

Lab motto: don’t be afraid to be wrong.

We are, ultimately, theorists. George Box’s aphorism “All models are wrong, some are useful” may be a cliche, but it doesn’t stop it being true.

Strong inference

We are not committed to a single “true” idea or single “true” method of analysis. We can disprove our own ideas, and break our own methods.

As scientists, we cannot do deduction, only inference. We cannot infer proof, only disprove. Thus, we aspire to do strong inference (Platt, 1964). For each problem, ideally we will:

1. create alternative hypotheses;

2. devise a crucial analysis or model that will exclude one or more hypotheses; and

3. perform the analysis (or build the model) that will obtain a clean result

Then: (1’) reiterate the procedure to refine the remaining possibilities.
In practice this means:

• Write down hypotheses, before starting analysis (or model building).

• Discuss them with others with constructive criticism (through informal chats, in lab meetings, or by sharing written text)

• Define outcomes expected of analysis testing (or models)

• Then analyse/build

Exploratory data analysis

What if we don’t have any hypotheses yet? In the absence of specific, disprovable hypotheses, we always have an aim to our analysis. That aim is a testable proposition.

For example “brain area X contains two independent populations that encode Y and Z”is a proposition. It is not yet a disprovable hypothesis, as that depends on our definitions of “independent”, “population”, and “encode”. Once we have defined those, then we can frame one or more hypotheses.

Exploratory data analysis is what we do to turn aims into hypotheses. At root, it is about constructing a model for the data, and using that model and its changes to generate hypotheses.

For example, we can define “independent populations” by using unsupervised clustering of neurons into groups based on their correlations. That idea contains two models. The first is a model of the relationships between independent time-series as a series of pairwise correlation measures. The second is a model of the relationships between those relationships: the clusters based on similar correlations. We might observe the existence of two strongly defined clusters of neurons, and define those as the basis for testing hypotheses about encoding. Disproving such hypotheses takes us back to Strong Inference.

Research collaboration care guide

We work with a lot of data directly from experimental labs. So that means we:

• Take care in all communication about private data. Discretion.

• Respect efforts of experimentalists in obtaining that data

• Treat their data with respect, and check it carefully

• Store their data well: multiple copies, backed-up. And we never ever work on the only copy of the data (see Scientific Conduct).

Open science

Open publication

We pre-print every paper on which it is our decision to make. Neuroscience papers go to bioRxiv. Technical papers to arXiv. Our policy is to post a pre-print when the manuscript is first sent to review by a journal at the latest. Pre-prints are then updated with every major revision to the manuscript that comes as a result of the reviews.

We publish open-access whenever possible, and always when essential. Both the UK Research Evaluation Framework and UK research funders have rules about making papers publicly available. For some journals, we do not need to publish open-access as either (a) their policy allows immediate posting of the post-print to a public repository (e.g. EuropePMC) or (b) they have an open archive, which falls within the rules. All papers have to be submitted to the University’s own paper repository, to abide by REF rules.

Open code

A computational paper without code is just an advert. Sometimes adverts are fine: the model is the medium for the message, and the message is what counts. But normally a computational paper stands or falls on the details of its computation. And those are only accessible from the code.

In practice this means:

• Share code whenever asked

• Always release code with publication

• When suitable, develop in public too

Open data

As we openly share code, so we would like to openly share the data too. But often it is not our data. So we make it politely clear to our collaborators that we would like to share the data to accompany the shared code in this best of all possible worlds. And that we will do everything in our power to help to do so, if necessary.
For example, we have been directly involved in making two data-sets open access:

• Voltage sensitive dye imaging data from the Aplysia pedal ganglion, as used in Bruno, Frost & Humphries (2017) eLife.

• Tetrode recordings in prefrontal cortex and behavioural data from rats learning rules in a Y-maze. Data from Adrien Peyrache and colleagures. Used in a range of papers, but made open access with us (we contributed the example analysis code to the repository) for Maggi, Peyrache & Humphries (2018) Nature Communications.

For future data to openly share, another option besides CRCNS is Nottingham’s Research Data Management Repository

Who works on what

We aspire to this division of labour:

• Everyone in the lab will work on at least one project that belongs to them. This project (or projects) will be your day-to-day work.

• Projects and their progress and especially the lack thereof due to problems should be discussed openly in the lab.

• We look for collaborative projects that will involve many or all of the lab members (most likely the senior members, PhD and above). Work on such projects will likely revolve around all-day hackathons, each hackathon focused on tackling a specific problem by harnessing the different skills and expertise within the lab. Our “spectral rejection” paper was based on work created during 5 hackathons spread over 6 months.