Skip to main content

Lab handbook

This is mostly aimed at PhD students, but some parts apply to everyone.

General expectations​

I don't think there's any one-size-fits all rule here for 'amount of work produced' and definitely not for 'number of papers'. I hope this will usually be clear from our weekly meetings, but please ask me if it isn't and I'd be very happy to discuss!

At least once a year we'll do a review -- some of this is part of the formal EMBL process anyway.

Meeting ^^^^^^^ Normally, we'll meet once a week for an hour, in person, to discuss your research. It's your meeting too, so think about what you'd like to discuss with me each week (and sometimes you might need to keep me to time).

Please do also feel free to talk to me outside of this, via slack, :ref:in person or on zoom<calendly>.

Please also do help one another with common issues, and arrange meetings with postdoc mentors in the group!

Working hours/remote working ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Typically, our working hours are from around 9am-5pm Mon-Fri. But, this is definitely a) flexible, b) somewhat governed by the buses.

It's generally more fun and more collaborative if we're around at the same time. Currently EBI's expectation is that you attend campus at least three days a week. I would prioritise days with meetings and seminars (typically Tues, Thurs and Fri). I'm usually in 3-4 days a week.

Holiday/leave ^^^^^^^^^^^^^ This is set by EMBL and Cambridge, a summary of their rules:

  • Cambridge PhD students are entitled to up to 8 weeks holiday each year.
  • Employees (postdocs etc) have 30 days a year (6 weeks), plus public holidays (8-9 further days). There is a booking system on Workday, and you can also roll over 15 days between years.
  • Interns in theory don't have a holiday allowance from EMBL, but you can take the same as employees (pro rata), just let me know.

There are other types of leave available for maternity/paternity, sickness, marriage and bereavement.

Problems ^^^^^^^^ If you have any problems with:

  • Services on campus (facilities)
  • Computing
  • Buses
  • HR issues

In the first instance there is an email for each of these use. If you're not getting anywhere, or the same thing happens again let me know -- there are meetings I can report these at which are more likely to reach the management (especially buses...)

Other problems we can discuss in confidence if needed, and everyone will also have another advisor or mentor too.

Non-research activities​

Teaching ^^^^^^^^ If you would like to do some teaching at Cambridge let me know and I can give you some advice. I'd recommend doing one set of supervisions in your 2nd or 3rd year, if you have time. Please note it's not guaranteed that this will be possible.

Courses ^^^^^^^ A reminder that in 2025 we are running two courses:

  • 1-5th September. BIOMICs hackathon.
  • 14-19th September. EMBO Practical Course: Methods for infectious disease modelling using genomics <https://www.ebi.ac.uk/training/events/infectious-disease-modelling-using-genomics-2025/#vf-tabs__section--tab2>__.

Producing training materials ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ One of our aims is to make our research accessible to others. This will include some of:

  • Implementing some methods as software
  • Writing documentation
  • Writing vignettes/tutorials
  • Doing talks and recording talks
  • Writing blog posts or similar non-paper formats
  • Making videos

These are all just as important as writing papers and methods!

Lab blog ^^^^^^^^ We have a lab website <https://www.bacpop.org>__ which currently includes a blog, and some how-to guides. I would like everyone to aim to write at least one post a year, either on a paper, some of your own work, or just an area of science. More details are on :doc:the page in this handbook<bacpop>.

I'd also suggest setting up your own personal website and/or blog. I can give some tips, if you'd like.

Social media ^^^^^^^^^^^^^^^^^^^^ Mostly on bluesky these days. We don't have a lab account, but many of us have personal accounts. If you want a bacpop.org handle rather than bsky.social we can set that up.

Reviews ^^^^^^^ Don't do too many paper reviews: aim to do around three times the number of papers you have submitted in the previous year.

If it's your first time getting one, this is a helpful guide: https://github.com/jtleek/reviews

Other points:

  • It's not magic, and won't fix all problems and catch every mistake
  • Be respectful to the authors, even if it's bad. Almost always, someone worked very hard on it.
  • Are your comments scientifically necessary, or just for interest? Try and indicate this to the authors.
  • Avoid a review along the lines of 'If I were to have done this study I would have done this, therefore you have to'. It's the author's study, not yours.

Research integrity​

There are courses you will take/have taken on this, but some general advice follows below.

Plagiarism ^^^^^^^^^^ Don't plagarise. My definition of plagarism is copying and pasting from other people's writing, without explicitly attributing it as a quote/citation.

By definition you can't self-plagarise -- it's fine to reuse your own words e.g. reformatting a paper into your thesis. Be more careful if it was text written jointly, or by someone else on a paper you are on.

I wouldn't be overly concerned about attributing every single picture in a powerpoint presentation, but it's good practise to include a citation at the bottom if it's a figure from a paper.

In a thesis, you can use figures from other people's papers, as long as you cite them and attribute credit in the legend.

Research ethics ^^^^^^^^^^^^^^^ Don't make up results. If you feel pressured to achieve a certain result or performance, but aren't seeing it, it's infinitely better to report the truth. Please talk to me if you aren't sure about specific cases on whether presentation of results might be misleading, as this can be more of a grey area.

Be careful about your work. If you're not sure about a result or it seems dubious, it's better to spend time confirming it now, rather than proceeding and having to redo more work later.

Writing ^^^^^^^ Write in google docs or overleaf so we can share comments and edits collaboratively.

Some general advice:

  • Write something down, then come back and edit it later. Don't try to make it perfect as it will get changed.
  • Send your writing in parts for review e.g. write the introduction first and send it to me.
  • Do the title and abstract last -- spend a good amount of time on each.
  • Be precise: instead of writing 'method X is better' write 'method X recalls 20% (13-34% 95% CrI) more genes'.
  • Don't try and fill up the word count by writing contentless sentences at the start and end of sections and paragraphs.
  • Make sure you include plenty of citations, and that where possible they are to the original piece of research. You don't need to add the same citation for every repeated use of a tool.
  • Be sparing with acronym use.
  • Spend a lot of time thinking about your figures, as they're what most people will look at.

Citations ^^^^^^^^^ Use one of the following citation managers:

  • Paperpile
  • Zotero
  • Mendeley
  • Papers

Paperpile is most popular.

Code practices/ethics ^^^^^^^^^^^^^^^^^^^^^

  • Share all code publicly.
  • Papers may often need a software repo, and an analysis repo for your other scripts and plots.
  • In analysis repos, include your plotting code, and a README describing what each script does.
  • Software repos should have full documentation, or a new section if you have added features.
  • Software repos should have some form of testing and continuous integration.
  • Software should be easily installable by non-experts. A conda package is typically recommended.
  • Use github and the bacpop group <https://github.com/bacpop/>__ for your code.
  • Use an Apache-2.0 or MIT license on your code.
  • Make a git repository for any code you write -- it will help you make breaking changes with impunity!
  • When making plots, you should be able to run through a script in a clean environment to generate the plot from scratch. Plots always need edits later, so this will save you loads of time.
  • For code or software which has been published, uses branches for changes, then pull requests to update the master branch when ready.
  • Don't aim for perfection in terms of reproducibility, do your best. Software is easier than scripts is easier than cluster runs.
  • Docker and singularity images are helpful, but don't aim for perfection.

Software maintenance ^^^^^^^^^^^^^^^^^^^^ Some tips from my own experiences:

  • Avoid minor dependencies, but don't reinvent the wheel.
  • Automatic deployment of releases.
  • Don't try to fix everyone's problems, especially if they're not directly with your package.
  • Feature requests can be prioritised however you like, but the default should probably be not to add them.
  • Ask people who email you to post on github instead.
  • Share the load with others.
  • Old packages can be retired -- don't be the maintaner for too many packages (how many is too many? Perhaps 2-3).
  • Make packages modular, not one big package which does everything.

Travel​

Group retreats ^^^^^^^^^^^^^^ Last year we did a group away day in Colchester in the summer, and I hope to do something similar again this year.

We also did a Cambridge day in Spring, which we will also try and repeat.

Conferences ^^^^^^^^^^^ My expectation would be that most people will be able to attend, each year:

  • One international conference, where you have submitted an abstract.
  • One conference at the conference centre, abstract or not.
  • One transversal theme retreat (Infection, Microbial Ecosystems or Theory).
  • One or two internal meetings (e.g. research day, lab day).
  • One or two meetings with collaborators in the UK.

In your first and likely second years you probably won't have an abstract ready yet, so international conferences are likely to happen later.

Upcoming conferences in 2024 to be aware of:

  • IB TT retreat (EBI) 7 & 8th April
  • ABPHM (Campus) 21st-23rd May
  • Europneumo (Azures) 20-23rd May
  • ISCB (Liverpool) 20-24th July
  • SMBE (Beijing) 20-24th July
  • IMMEM (Porto) 17-20th Sep
  • Genome Informatics (CSH) 5-8th Nov

Also MCEB <https://mceb2023.sciencesconf.org/resource/page/id/5>__, but I'm not sure if it's happening in 2025.