lab_managers.Rmd

---
title: Resources for lab managers
output:
  html_document:
    toc: true
    toc_float: true
---

As a lab manager, your role is to help others develop their code and you may also develop code directly yourself at times.
Your primary responsibilities are not only to help developers create code that is the least wrong, but perhaps more importantly guide the lab developer(s) technical skill development.

## General tips:  

- As a senior member of the lab (at least when it comes to the technical aspects of code), you will want to achieve an **open and empathetic communication line** with the lab developers. You will be their direct support when it comes to troubleshooting or problems that arise.
- It may take time and trial and error, but you will need to work with the lab developer(s) on striking a communication balance. You want to **make it clear that you are available to help whenever the lab developers are stuck**; but you will also want encourage lab developers to take time to run, test, and troubleshoot. This delicate balance is something that each lab developer will need to determine with your and your lab leader's guidance.  
- As the primary reviewer of the code, it is your responsibility **to ensure the correctness and efficiency of the code**.
- Take a **"no blame autopsy"** stance when digging into code problems within your lab. By that we mean blame never helps anyone and only serves to make things uncomfortable or even toxic. You want the members of your lab to readily come to you with mistakes rather than encouraging them to hide them from you. Mistakes are human and generally just a product of a system and should not be attributed to character flaws. Instead, if you find a mistake in code or elsewhere (particularly if a pattern arises), empathetically and openly discuss with your lab:
  - What can you (as the lab manager) do to help support the mentee and help both of you find a solution to reduce the chances of this mistake being repeated?
  - Be empathetic and reassuring that **finding the mistake is a good thing because now we all can learn from it**.
- It's a great idea for you and the other members of your lab to **get involved** with [online and in person coding groups](./more_resources.html#groups-for-discussing-code) and this includes potentially starting a within lab coding group of your own that meets on a regular basis to review code.

## General recommended reading for you 

- For tips for writing good code and creating reproducible projects: [Reproducibility in Cancer Informatics](https://jhudatascience.org/Reproducibility_in_Cancer_Informatics/)
- For tips for writing pull requests: [Engaging in Code Review as an Author](https://jhudatascience.org/Adv_Reproducibility_in_Cancer_Informatics/engaging-in-code-review---as-an-author.html) by Candace Savonen.
- For tips for reviewing pull requests: [Engaging in Code Review as an Reviewer](https://jhudatascience.org/Adv_Reproducibility_in_Cancer_Informatics/engaging-in-code-review---as-a-reviewer.html) by Candace Savonen.
- For more on effective code review: [A zen manifesto for effective code reviews](https://www.freecodecamp.org/news/a-zen-manifesto-for-effective-code-reviews-e30b5c95204a/) by Jean-Charles Fabre.
- About [Good scientific coding practices](https://github.com/AlexsLemonade/training-modules/blob/master/intro-to-R-tidyverse/00c-good-scientific-coding-practices.md) by the Childhood Cancer Data Lab.
- [Tips for debugging code from the Childhood Cancer Data Lab](https://github.com/AlexsLemonade/training-modules/blob/master/intro-to-R-tidyverse/00b-debugging_resources.md)
- For good practices on code review: [Best practices for Code Review](https://smartbear.com/en/learn/code-review/best-practices-for-peer-code-review/) from SmartBear.

**See our list of [recommended resources](./more_resources.html) to get going!**