Onboarding
What this part of the lab does, and guidance for how to get started.
§1 Overview of the computational wing of the Raredon Lab
The computational wing develops tools, methods, and analyses to investigate cell-to-cell signaling and tissue-scale phenomena — the patterns and behaviors that emerge from many interacting cells and cannot be understood by studying single molecules or single cells in isolation. The work spans tissue biology, tissue engineering, and computational biology, and is built to be generalizable: methods and findings should extend readily to other tissues, other labs, and other questions beyond those immediately under study. A defining commitment is using visualization to make structure legible — understanding what is in a dataset before measuring it, then developing purpose-built visuals to communicate findings to computational and non-computational colleagues alike. Much of the lab's data is graph-structured, or can be meaningfully formalized as a graph, and this geometric lens shapes how tools are built and results are interpreted. Computational scientists here serve the larger wet-lab and clinical team by translating biological measurements into rigorous, reproducible, shareable quantitative insight. The work demands sustained curiosity, careful habits of documentation, and the willingness to explain what you are doing in plain language to anyone who asks.
§2 Why this manual exists
A computational lab is as complex as a wet lab. It has protocols, best practices, and standards that are just as essential to producing high-quality, reproducible, broadly applicable science. The practices described here make the work more durable: easier for collaborators to use, easier for reviewers to trust, and easier for future scientists to build on.
Writing these practices down is also a statement of respect for the people who join this lab. Standards passed on informally are uneven, easily forgotten, and impossible to improve collectively. A written record gives everyone the same foundation to work from, and something concrete to update as tools and methods evolve.
Read this manual once, front to back, when you join. Confirm with the PI that you have done so, and bring any questions to your second 1:1. Refer back to specific sections whenever you need a reminder, and use it to orient others when the time comes. The manual will be revised over time as the lab's practices develop.
§3 Your first week
The following checklist covers the practical setup that should be complete by the end of your first week. Work through it in roughly this order and ask for help whenever you need it.
-
1
Read this manual
Start here, front to back. Note any questions as you go. You do not need to memorize it; you need a map of what is here and where to find it.
-
2
Set up your computing environment
Follow Document 02 to install required software and configure your machine and HPC access. Do not skip steps or defer items: a properly configured environment is the foundation for everything else.
-
3
Schedule your recurring 1:1 with the PI
Set up a weekly meeting with the PI. This is your primary channel for scientific direction, project feedback, and discussing blockers. Establish it in the first week so it becomes part of your routine immediately.
-
4
Get your calendar and communications set up
Configure your Yale Outlook calendar. Make sure you are invited to all recurring lab meetings and added to the relevant mailing lists. Join the lab Slack workspace, the primary channel for day-to-day questions and coordination.
-
5
Meet with a senior lab member to complete your setup
Schedule a dedicated setup meeting with the senior computational scientist in the lab. This session covers HPC access, data object locations, lab-specific workflows, and any setup items not covered by the general computing environment document.
-
6
Get access to the relevant data
Identify the primary datasets you will be working with and confirm access. Large data objects live on the lab HPCs, the Raredon Lab server, or the RaredonLab SharePoint. Know which applies to your project before you need the data for the first time.
-
7
Review the setup checklist with the PI
At your second 1:1 meeting, walk through the setup checklist together. This is also the time to ask any questions that came up while reading this manual and to get clarity on your initial project focus.
§4 Who to ask for what
Different questions belong in different places. Getting this right saves time for everyone.
| Type of question | Where to bring it |
|---|---|
| General questions that do not need an immediate answer — computational methods, tool usage, data interpretation, anything a lab member might know | Slack. Post in the appropriate channel. Anyone in the lab can respond, and the answer becomes searchable history for others. |
| Computing environment setup, HPC access, Git configuration, lab-specific workflows | Senior computational scientist. Schedule a dedicated meeting early on (see §3, step 5). For specific issues later, Slack is usually fine. |
| Scientific direction, project prioritization, authorship, collaboration decisions | PI (weekly 1:1). Bring an agenda. If something is urgent and cannot wait, send a Slack message flagging it. |
| Stuck on a coding problem for more than an hour | Claude or AI tools first, then Slack, then 1:1. See Document 06 for guidance on using AI effectively. Ask for help early. |
| Administrative or logistical matters | Consult Yale departmental resources or ask the PI to point you to the right contact. |
§5 Tools and resources to learn
The following tools form the core computational stack. Familiarity with the ones relevant to your current project is the starting expectation; the others should be learned actively over time. Each entry includes a link to the best starting point.
R environment and core packages
| Tool | What it is | Start here |
|---|---|---|
| R | Primary programming language for analysis and visualization | R for Data Science (free online) |
| RStudio / Positron | IDEs for writing and running R code. Positron is the newer Posit IDE and is preferred. | Positron documentation |
| ggplot2 | Primary plotting library. The grammar of graphics in R. | ggplot2 documentation · Fundamentals of Data Visualization (free) |
| dplyr | Data manipulation: filtering, grouping, summarizing, joining. | dplyr documentation |
| cowplot | Publication-quality figure composition and layout. | cowplot documentation |
| ComplexHeatmap | Highly customizable heatmaps for high-dimensional data. | ComplexHeatmap reference (free) |
| sf | Spatial data manipulation and analysis in R. | sf documentation |
Single-cell and spatial analysis
| Tool | What it is | Start here |
|---|---|---|
| NICHES | Lab-developed framework for quantifying cell-to-cell communication at single-cell and spatial resolution (R) | NICHES on GitHub |
| Seurat | Primary R framework for single-cell RNA-seq analysis and multi-modal integration | Seurat vignettes (Satija Lab) |
| scanpy | Primary Python framework for single-cell analysis (scverse ecosystem) | scanpy documentation |
| XeniumExplorer | 10x Genomics tool for visualizing and exploring Xenium spatial transcriptomics data | 10x Genomics Xenium Explorer |
Learning resources
| Resource | What you will learn |
|---|---|
| R for Data Science, 2nd ed. (Hadley Wickham) | Core R programming, tidyverse workflow, and data science fundamentals. Start here if you are new to R. |
| Fundamentals of Data Visualization (Claus Wilke) | Principles of effective scientific data visualization. Recommended for everyone, regardless of experience level. |
| Orchestrating Single-Cell Analysis with Bioconductor | Comprehensive reference for single-cell analysis in R, from QC through integration and visualization. |
| Analysis of scRNA-seq Data (Cambridge) | Free course covering statistical foundations and practical workflows for single-cell transcriptomics. |
| ComplexHeatmap Complete Reference | Everything you need for building complex, publication-quality heatmaps in R. |
| Claude (Anthropic) | AI assistant for coding help, literature questions, writing, and debugging. See Document 06 for how to use it effectively. |
The resources above cover methods. Equally important is reading the primary scientific literature on the biological and computational topics you encounter. When a method or dataset touches a field you do not know, go learn about it. Lab meeting is a good venue for sharing what you find.
§6 What a good week looks like
There is no single template for a productive week in a computational lab. Projects vary, timelines vary, and the nature of the work shifts between phases of exploration, analysis, and writing. Certain habits, though, characterize work that compounds well over time.
- Eight hours of focused work per day. Computational science rewards sustained concentration. Fragmented time produces fragmented work.
- Clear milestones and task completion. Know what you are trying to accomplish this week, and finish the things you start. Partial analyses are hard to hand off and easy to lose track of.
- Daily commits and pushes. Code that is not on GitHub cannot be reviewed, helped with, or built on. See Document 03.
- Well-documented code. Write it as if someone else will need to run it next week. They might. See Document 04.
- Reading. Set aside time each week to read, across both computational methods and biology. The two must develop together. Methods without biology produce technically competent but scientifically hollow analysis.
- Communication. Share what you are working on. Keep the PI and your colleagues updated. Ask questions when you are stuck.
- Availability. Be reachable on Slack during working hours and responsive to questions from colleagues who may need your help or input.
Reliability in computational science means code that produces exactly what you say it produces, and where you have verified that this is the case. No one will check your work automatically. The responsibility of knowing precisely what your analysis is doing (why each step is there, whether the output is what you expect, and whether that expectation is the right choice) rests entirely with you.
This judgment develops over time. Early on, it means slowing down to check intermediate outputs, reading documentation carefully, and asking whether the numbers you are seeing make biological sense. Over time it becomes intuition, and developing it is one of the most important parts of becoming a skilled computational scientist.
§7 Being a good colleague
Communicate your work
The PI cannot help with what they cannot see. Communicating regularly about what you are working on, in your weekly 1:1 and at lab meetings, is how scientific problems get noticed before they become costly, and how the team learns from your work. Regular communication is how a computational team functions.
Help others troubleshoot
One of the most valuable things you can do for a colleague is point them to work that already exists on GitHub, to a vignette that addresses their question, or to a helper function that solves their problem. The lab's collective infrastructure is only useful if people know it exists and can access it. Be generous with what you know.
Ask for help early
Do not spend more time than necessary stuck on a problem alone. Use Claude, documentation, and search first. If that does not resolve it, ask on Slack or in your 1:1. Asking for help early is how science moves faster. The cost of staying stuck silently is always higher than the cost of asking.
Finish what you start
Take ownership of your projects. That means completing analyses you have begun, not starting things you cannot finish, and not taking over someone else's work without explicit agreement. It also means being generous: share your methods, your functions, and your findings openly within the lab and, when the time is right, with the wider scientific community.
§8 The four steps of data science
A useful frame for thinking about computational work is the following progression. Every analysis, regardless of scale or complexity, passes through these four stages.
Iteration between steps is normal, and these stages are not always strictly sequential in practice. Losing track of which step you are in, and jumping to conclusions before adequately exploring the data, is one of the most common sources of error in computational biology. Return to this frame whenever a project feels muddled.
§9 Things worth remembering
These are observations that tend to change how people approach the work. They are worth reading again at different stages of a project.