The Cohort and the Mentorship Structure

There are fourteen of you.

That number is not an accident, and I want to start by telling you why. Faculty mentors at the Aspiring Scientists Summer Internship Program (ASSIP) typically take somewhere between two and fifteen students per summer; fourteen is at the high end of that range, and I picked it deliberately. Three students would have been easier on me. It would also have been worse for you. With three, there is no diverse pool of projects to learn across — when Maya is wrestling with an instrumental-variables identification problem, only Devon and Priya are watching, and neither of them happens to be working on anything close enough to recognize the same problem in their own data. With fourteen, the chance that someone in the room has just survived the exact bug you are stuck on goes up sharply. So does the chance that someone reads your draft and catches the sentence that sounds confident but is actually wrong.

Fourteen is also where I draw the line. Past that, you stop being a cohort and start being an audience. I would no longer be able to keep a real picture in my head of where each of you is on your project, what your last result looked like, and which specific worry is keeping you up at night. I want to be able to keep that picture. So: fourteen.

The layered mentorship structure

One faculty mentor cannot give fourteen students enough one-on-one time. That is just arithmetic. So the mentorship is layered, and you will move through all three layers in any given week.

Layer 1 — Faculty mentor (me). I hold a weekly group session every Monday morning, where we set the week’s research goals, work through one shared methodological topic together, and surface anything that came up over the weekend. Outside the group session I keep 1:1 office hours that every student can book, plus drop-in time for anyone who hits a wall and needs the wall removed today. My job at this layer is the things that are hardest to delegate: framing your research question so it is actually answerable, telling you when a result is real and when it is a coincidence, and writing on your draft in the margins.

Layer 2 — Pod sub-leaders. Four PhD students and research assistants from my lab each lead a research-pod of three to four of you. They run daily standups (fifteen minutes, what you did yesterday, what you are doing today, what you are stuck on), they read your code first, and they are the person you message first when something is broken at 4 p.m. on a Wednesday. Sub-leaders are close enough to your work to know its details and far enough along in their own research careers to recognize the patterns. They are also closer in age to you than I am, and they remember what it was like to feel lost in front of a regression output last year, not twenty years ago.

Layer 3 — Peer pods. Inside each sub-leader’s pod, the three or four of you become each other’s first reviewers. You pair-program when one of you is debugging, you read each other’s drafts before they go to the sub-leader, and on days when the standup is short you compare what each of you tried. The peer pod is where most of the daily learning actually happens — not because peers are smarter than mentors, but because explaining your stuck-point out loud to someone who is also stuck is often what unsticks it.

Think of the three layers as different time scales. Peers are minutes-to-hours. Sub-leaders are hours-to-days. I am days-to-weeks. The structure works when you use the layer that matches your timescale, and it breaks when you save every question for me — by the time it reaches my desk it has cost you four days you did not need to spend.

Cohort culture

I want to name the culture out loud, because cultures that are not named tend to drift.

Intellectual honesty. When something does not work, say so. When a result looks too good, treat it as suspicious before you treat it as a discovery. When a peer’s draft has a problem, point at the problem directly. Everyone in this cohort is here because they can take a real critique and use it; protecting each other from real critique would be the unkindest thing we could do.

Kind to the person, tough on the work. This is the rule we lean on hardest, and it is worth a chapter of its own — which it gets, in Chapter 8.4, where we talk about how to give and receive a real research review. The short version: the sentence “this paragraph is confused” is a useful piece of information about a paragraph. The sentence “you are confused” is a useful piece of information about nothing. We say the first kind. We do not say the second.

Generous code review. When a podmate posts code for review, read it as if you are going to defend it tomorrow. Catch the off-by-one. Notice the missing standard-error cluster. Flag the variable name that could mean two things. You will get this same care back when it is your turn.

Shared wiki. Every solved problem, every working code recipe, every “here is what finally fixed the WRDS connection” goes into the cohort wiki. The wiki is how fourteen people’s accumulated debugging stops being fourteen separate piles of frustration.

The symposium is a team win. Every one of you presents a poster at the ASSIP Research Symposium on Wednesday, August 12, 2026 in front of Mason faculty, families, College of Science leadership, and the Mason News press. That day is not a competition between you. It is the cohort, together, walking into a room and showing what fourteen people can do in eight weeks when they take real standards seriously. You win or you lose as a group, and I am going to keep saying so.

A note on the fourteen

The “fourteen of you” in this book is a structural placeholder — the size of the cohort and the mentorship math built around it. The actual names of your fourteen live in the cohort wiki at wiki/cohort/, not in the printed book, because the wiki updates and the book does not. When you arrive at orientation on Thursday, June 18, 2026, that page will show you who your podmates are, who your sub-leader is, and the active project of every other student in the cohort.

Throughout the textbook itself you will keep meeting the same five fictional students — Maya, Devon, Priya, Sam, and Leah. They are not your real cohort. They are a recurring cast we use for worked examples, because writing “an earlier student” fourteen different ways is worse than letting you get to know five characters and their habits of mistake. Maya tends to over-engineer. Devon trusts the first regression he runs. Priya catches what nobody else catches but waits too long to share it. Sam ships fast and breaks things. Leah is the one who finally reads the documentation. Treat them as colleagues you are reading about; treat the fourteen people whose names are in the wiki as colleagues you are working with.

Communication, logistically

Code lives on GitHub — one repository per student, all linked from the wiki. Your sub-leader has read access; your podmates have read access; I have read access. Pull requests are how you ask for review.
Schedule, projects, FAQ, debugging recipes live on the cohort wiki. Bookmark it on day one.
Synchronous standups and chat happen on Slack or Discord — the platform will be finalized at orientation. Daily pod standups, cohort-wide announcements, and the “I am stuck right now” channel all live there.

Projects and the timeline

Every student picks a project on day one of Week 1. You may pick from the menu of Gao-lab threads — fair lending, common ownership and the supply chain, intraday momentum, and the other published lines of work the book draws on — or you may propose your own, provided your sub-leader and I agree the question is answerable on public data in eight weeks. The pre-analysis plan (PAP) is filed by the end of Week 5. From that point forward, what counts as a result is fixed in writing; this is how we keep ourselves honest.

In Week 8 the cohort runs a dress-rehearsal poster session on Monday, August 10, 2026, with sub-leaders and me as the audience. Two days later the real symposium happens. The dress rehearsal is non-optional and it is not ceremonial — it is the last chance to fix the figure that does not read from across the room.

A frank note on remote-only

Prof. Gao’s 2026 ASSIP slot is officially remote-only. I want to acknowledge what that costs. The hallway conversation, the whiteboard you both stand in front of, the dinner after a long day where someone says the thing they would not say in a meeting — those are real, and remote work does not get them for free. The wiki and the daily standups are the deliberate answer to that loss: small groups, every day, on camera, with a sub-leader who knows your work and a peer pod that knows your code. We will not pretend the loss is zero. We will work hard enough that, by August 12, you will not feel it.

Welcome to the cohort.

# The Cohort and the Mentorship Structure There are fourteen of you. That number is not an accident, and I want to start by telling you why. Faculty mentors at the **Aspiring Scientists Summer Internship Program (ASSIP)** typically take somewhere between two and fifteen students per summer; fourteen is at the high end of that range, and I picked it deliberately. Three students would have been easier on me. It would also have been worse for you. With three, there is no diverse pool of projects to learn across — when Maya is wrestling with an instrumental-variables identification problem, only Devon and Priya are watching, and neither of them happens to be working on anything close enough to recognize the same problem in their own data. With fourteen, the chance that *someone* in the room has just survived the exact bug you are stuck on goes up sharply. So does the chance that someone reads your draft and catches the sentence that sounds confident but is actually wrong. Fourteen is also where I draw the line. Past that, you stop being a cohort and start being an audience. I would no longer be able to keep a real picture in my head of where each of you is on your project, what your last result looked like, and which specific worry is keeping you up at night. I want to be able to keep that picture. So: fourteen. ## The layered mentorship structure One faculty mentor cannot give fourteen students enough one-on-one time. That is just arithmetic. So the mentorship is layered, and you will move through all three layers in any given week. **Layer 1 — Faculty mentor (me).** I hold a **weekly group session every Monday morning**, where we set the week's research goals, work through one shared methodological topic together, and surface anything that came up over the weekend. Outside the group session I keep **1:1 office hours** that every student can book, plus drop-in time for anyone who hits a wall and needs the wall removed today. My job at this layer is the things that are hardest to delegate: framing your research question so it is actually answerable, telling you when a result is real and when it is a coincidence, and writing on your draft in the margins. **Layer 2 — Pod sub-leaders.** Four PhD students and research assistants from my lab each lead a research-pod of three to four of you. They run **daily standups** (fifteen minutes, what you did yesterday, what you are doing today, what you are stuck on), they read your code first, and they are the person you message first when something is broken at 4 p.m. on a Wednesday. Sub-leaders are close enough to your work to know its details and far enough along in their own research careers to recognize the patterns. They are also closer in age to you than I am, and they remember what it was like to feel lost in front of a regression output last year, not twenty years ago. **Layer 3 — Peer pods.** Inside each sub-leader's pod, the three or four of you become each other's first reviewers. You **pair-program** when one of you is debugging, you **read each other's drafts** before they go to the sub-leader, and on days when the standup is short you compare what each of you tried. The peer pod is where most of the daily learning actually happens — not because peers are smarter than mentors, but because explaining your stuck-point out loud to someone who is also stuck is often what unsticks it. Think of the three layers as different time scales. Peers are minutes-to-hours. Sub-leaders are hours-to-days. I am days-to-weeks. The structure works when you use the layer that matches your timescale, and it breaks when you save every question for me — by the time it reaches my desk it has cost you four days you did not need to spend. ## Cohort culture I want to name the culture out loud, because cultures that are not named tend to drift. **Intellectual honesty.** When something does not work, say so. When a result looks too good, treat it as suspicious before you treat it as a discovery. When a peer's draft has a problem, point at the problem directly. Everyone in this cohort is here because they can take a real critique and use it; protecting each other from real critique would be the unkindest thing we could do. **Kind to the person, tough on the work.** This is the rule we lean on hardest, and it is worth a chapter of its own — which it gets, in Chapter 8.4, where we talk about how to give and receive a real research review. The short version: the sentence "this paragraph is confused" is a useful piece of information about a paragraph. The sentence "you are confused" is a useful piece of information about nothing. We say the first kind. We do not say the second. **Generous code review.** When a podmate posts code for review, read it as if you are going to defend it tomorrow. Catch the off-by-one. Notice the missing standard-error cluster. Flag the variable name that could mean two things. You will get this same care back when it is your turn. **Shared wiki.** Every solved problem, every working code recipe, every "here is what finally fixed the WRDS connection" goes into the cohort wiki. The wiki is how fourteen people's accumulated debugging stops being fourteen separate piles of frustration. **The symposium is a team win.** Every one of you presents a poster at the **ASSIP Research Symposium on Wednesday, August 12, 2026** in front of Mason faculty, families, College of Science leadership, and the Mason News press. That day is not a competition between you. It is the cohort, together, walking into a room and showing what fourteen people can do in eight weeks when they take real standards seriously. You win or you lose as a group, and I am going to keep saying so. ## A note on the fourteen The "fourteen of you" in this book is a structural placeholder — the size of the cohort and the mentorship math built around it. The **actual names of your fourteen** live in the cohort wiki at `wiki/cohort/`, not in the printed book, because the wiki updates and the book does not. When you arrive at orientation on **Thursday, June 18, 2026**, that page will show you who your podmates are, who your sub-leader is, and the active project of every other student in the cohort. Throughout the textbook itself you will keep meeting the same five fictional students — **Maya, Devon, Priya, Sam, and Leah**. They are not your real cohort. They are a recurring cast we use for worked examples, because writing "an earlier student" fourteen different ways is worse than letting you get to know five characters and their habits of mistake. Maya tends to over-engineer. Devon trusts the first regression he runs. Priya catches what nobody else catches but waits too long to share it. Sam ships fast and breaks things. Leah is the one who finally reads the documentation. Treat them as colleagues you are reading about; treat the fourteen people whose names are in the wiki as colleagues you are working with. ## Communication, logistically - **Code** lives on **GitHub** — one repository per student, all linked from the wiki. Your sub-leader has read access; your podmates have read access; I have read access. Pull requests are how you ask for review. - **Schedule, projects, FAQ, debugging recipes** live on the **cohort wiki**. Bookmark it on day one. - **Synchronous standups and chat** happen on **Slack or Discord** — the platform will be finalized at orientation. Daily pod standups, cohort-wide announcements, and the "I am stuck right now" channel all live there. ## Projects and the timeline Every student picks a project on day one of Week 1. You may pick from the menu of **Gao-lab threads** — fair lending, common ownership and the supply chain, intraday momentum, and the other published lines of work the book draws on — or you may **propose your own**, provided your sub-leader and I agree the question is answerable on public data in eight weeks. The **pre-analysis plan (PAP)** is filed by the end of **Week 5**. From that point forward, what counts as a result is fixed in writing; this is how we keep ourselves honest. In **Week 8** the cohort runs a **dress-rehearsal poster session on Monday, August 10, 2026**, with sub-leaders and me as the audience. Two days later the real symposium happens. The dress rehearsal is non-optional and it is not ceremonial — it is the last chance to fix the figure that does not read from across the room. ## A frank note on remote-only **Prof. Gao's 2026 ASSIP slot is officially remote-only.** I want to acknowledge what that costs. The hallway conversation, the whiteboard you both stand in front of, the dinner after a long day where someone says the thing they would not say in a meeting — those are real, and remote work does not get them for free. The wiki and the daily standups are the deliberate answer to that loss: small groups, every day, on camera, with a sub-leader who knows your work and a peer pod that knows your code. We will not pretend the loss is zero. We will work hard enough that, by August 12, you will not feel it. Welcome to the cohort.