Lab Meeting on 08 August 2019
This lab meeting included some discussions ranging from READMEs, to academic culture, and studies on bias.
Celebrations and cool things to share π
Kirstie has posted blog posts from lab meeting on 18 and 25 July! π π
- https://whitakerlab.github.io/blog/2019-07-18-lab-meeting
- https://whitakerlab.github.io/blog/2019-07-25-lab-meeting
Louise has recently been going through some problems from Project Euler in the REG’s coding club. There are some really interesting puzzles there which are definitely useful for getting up to speed in a new programming language! The group have been using some niche programming languages, such as “post-script” and “haskell”. Louise is going to learn F#, a functional language. Project Euler is good because there are lots of little challenges which don’t take too long to solve and can be broken down into steps.
Sarah is going through a phase of learning new stuff in Python. She has been autogenerating log files, and html requests, and as a side project working on a bot which automates with GitHub’s API.
Ang recoommended LeetCode as a great way to learn code. π π
Louise and Sarah made the point that coders are pro level googlers - it’s not cheating!
Questions we’re thinking about β
Kirstie loved being in a breakout discussion on code review at Neurohackademy. The key point was short code: only 50 lines long (200 absolute max). Kirstie would love to see if lab members can get some eyes on each other’s code - maybe just one or two functions each. She also shared some useful code review resources:π
- Code review in Turing Way: https://the-turing-way.netlify.com/reviewing/reviewing.html
- Notes from breakout discussion: https://github.com/alan-turing-institute/the-turing-way/issues/656
Louise has been thinking that it’s good if the lab meetings can get into specifics. Her project has individual commits which are manageable chunks. She suggested a code review in that style.
Sarah was wondering what kind of project lab members would like to do together to build trust and learn how we can help each other?
Ang wanted to know if there were any guides for researchers to protect themselves under the current open science system? He pointed out there have been instances where papers have been borrowed from but not cited, or reviewers have held onto submissions and published their own papers in the meantime.
We discussed how protecting researchers may not be the right way to solve the problem of plagerism in science, and that a culture shift is needed to make it not okay to steal people’s work.
One way to do that is researchers only publishing in open journals, and moving away from publish or perish. This is a great TEDx talk by Rachael Ainsworth on Academia’s broken culture.
Yini shared a paper about bias: Potential reporting bias in neuroimaging studies of sex differences by David, Naudet et al. (2018). doi: 10.1038/s41598-018-23976-1. She has been thinking about bias a lot when it comes to gender and science: more than 80% of researchers will report that there is a gender difference, but only 2 studies show this. She thought a reason might be that people like to report a positive result, and this contributes to the bias.
Yini summarised findings from this paper for the lab group. Overall, 158 papers (88%) reached “positive” conclusions in their abstract and presented some foci - locations in the brain - related to sex differences.
To quote from the abstract:
Few articles (nβ=β2) had titles focused on no differences or on similarities (nβ=β3) between sexes… There was no statistically significant relationship between sample size and the number of foci… The extremely high prevalence of “positive” results and the lack of the expected relationship between sample size and the number of discovered foci reflect probable reporting bias and excess significance bias in this literature.
Anything else
We also shared some READMEs from our projects, and discussed what different purposes they served.
Louise shared one on Traffic mobility.
It’s currently a private repo but it will go public at some point.
It contains the docker-compose
file that sets up the traffic visualisation project Louise showed in the slides for a previous lab meeting (see the lab meeting blog from 25 July).
Louise’s README is also the place where her and her team drop any useful documents from meetings and planning sessions.
This README is all about the general: what you should do while you’re here, and how to get it up and running.
Sarah shared her README: binderhub-deploy button. This β¨automagicallyβ¨ deploys a BinderHub to Azure using a button click! This README is basically about how you use the software. There are three ways you can run the repository, so it goes through all three ways of doing it.
Georgia shared the README for her citizen science project. This README explains about the project and how to contribute. Beacuse it’s not only for a technical audience, it tries to explain routes to contribution clearly, and in an encouraging way.
Ang shared a README from a project he’s working on which aims to develop clincal-relevant biomarkers for schizophrenia. It’s currently a private repo but it will go public at some point. It links to a jupyter notebook to replicate the results of the study so that others can calculate the published biomarker for different neuroimaging data.