Sync

We meet in person every Wednesday in A214 Langley. The morning section meets from 9:00 - 10:50 am and the afternoon section meets from 1:00 - 2:50 pm. You are expected to attend all meetings.

Onboarding Phase

Before we can function as a software engineering team, every individual must master the tools of the trade. Weeks 1 through 4 function as a technical bootcamp. During this phase, our goal is not “product delivery,” but “individual competency.” We focus entirely on setting up your development environment and passing the ticket.

Unlike the Sprint phase, where you are expected to self-manage, the onboarding phase is high-touch and instructional. We use the following format for these sessions:

Cadence

The Concept Check (0:00 – 0:20)

We begin with a brief review of the Async material to ensure conceptual understanding. We will address the “Why” before the “How.” (e.g., Why do we use SSH keys instead of passwords? Why does Pixi exist?)

The Code-Along (0:20 – 0:50)

You will open your terminal; I will open mine. We will perform the core technical tasks of the week simultaneously. This is a “follow-the-leader” exercise where we configure your specialized research environment in real-time. If you encounter a path error or permission denied message, we stop and fix it immediately. By the end of this block, you should have a working setup that allows you to attempt the ticket.

The Open Lab (0:50 – 1:50)

The second hour is dedicated to completing your tickets. You will work individually or in pairs to generate the required artifacts. The instructor will circulate to sign off on completed tickets or assist with debugging.

Visual Status Signaling

Because we move fast during the Code-Along, we need a high-bandwidth way to communicate status without interrupting the flow. We will use the sticky note system:

  • Green Sticky Note: “I am caught up,” “My code works,” or “I have completed the task.” Place this on your laptop lid so the instructor can see the room is ready to move on.
  • Pink Sticky Note: “I am stuck,” “I have an error,” or “I need help.” Place this on your laptop lid immediately.

This immediate “hand-raising” support model applies ONLY to Weeks 1–4. Starting in Week 5 (Sprints), you will graduate to the professional “Help Ticket” system described below.

Sprints

Starting in Week 5, once the teams are chartered and the Sprints begin, this course shifts gears. We move from an instructional model to a production model.

To mirror the environment of a high-performance Research Software Engineering (RSE) team, our synchronous sessions will no longer function as lectures with guided activities. Instead, we treat every class meeting as a live engineering sprint.

We follow a strict Standard Operating Procedure (SOP) to maximize development time and ensure technical blockers are resolved immediately.

Cadence

The Triage (0:00 – 0:15)

Class begins with a Stand-Up. We will project the course Kanban board (GitHub Projects) on the main screen. We do not waste time on status updates like “I wrote some code.” We focus entirely on friction.

We identify which teams are Blocked. If your team is stuck on a technical hurdle that has stalled progress for more than 24 hours, you are flagged. If another team has solved a similar problem previously, we will assign a cross-team consultation. This ensures that the collective intelligence of the room is used to solve problems, rather than relying solely on the instructor.

The Micro-Clinic (0:15 – 0:35)

There are no hour-long lectures in this phase. Instead, we use “Just-in-Time” teaching. Based on the code you pushed and the Async assignments, the instructor will identify a common pain point across the class. For 20 minutes, we will focus on that single specific issue. This is usually a live-coding demonstration where we solve a real bug together.

Deep Work (0:35 – 1:30)

This is the core of the course. For 55 minutes, the teams work on their current Sprint deliverables. During this time, the instructor acts as the Chief Technology Officer (CTO). I will not be lecturing; I will be circulating. My role is to unblock you, review your architecture, and help you debug complex errors. However, to access this help, you must follow the Help Ticket Protocol (see below).

The Merge (1:30 – 1:50)

We stop coding 20 minutes before the end of class to conduct a retrospective. We will pick one specific Pull Request or Repository from the day’s work and project it on the screen.

This is a “safe roast.” We will analyze the code together—highlighting what was done well (e.g., “Look at this clean error handling”) and what needs improvement (e.g., “Why is this file path hard-coded?”). This creates a feedback loop where you learn from your peers’ code, not just your own.

Rules of Engagement

To simulate a professional environment, we enforce specific behaviors during the “Deep Work” sessions.

The “Help Ticket” System

In a professional remote team, you cannot simply raise your hand and wait for a senior engineer to walk over. You must articulate your problem in writing. We practice that here.

Do not raise your hand if you are stuck.

If your group encounters an error:

  1. Attempt to solve it using the error message and documentation.
  2. If you are still blocked, go to your team’s GitHub Repository.
  3. Open an Issue.
    • Tag: help-wanted
    • Assignee: @DRI
    • Content: You must paste the specific error code, the file path, and a bulleted list of the attempts you have already made to fix it.

I will monitor the GitHub notification feed and visit teams based on the priority and clarity of their tickets. If the problem is not in an Issue, the problem does not exist.

Mob Programming

Teams are not permitted to “divide and conquer” silently during class (e.g., “You do the CSS, I’ll do the Python”). This leads to siloed knowledge and integration nightmares. During Sync sessions, we use Mob Programming:

  • One Monitor: The team gathers around a single screen.
  • The Driver: Has their hands on the keyboard. They focus on syntax and typing.
  • The Navigators: Review the code in real-time, spot typos, and guide the high-level logic.

You must rotate the “Driver” role every 20 minutes.

Special Events

While most weeks follow the standard protocol, we occasionally break the routine to test specific engineering resilience skills:

The Architecture Review (Week 6): Laptops are closed. We use whiteboards only to map out data flows before writing a single line of code.

The Chaos Monkey (Week 8): You will clone a neighboring team’s repository. You have 45 minutes to “break” their code—finding inputs that cause crashes or unhandled exceptions. You earn points for breaking their code; they earn points for handling the errors gracefully.

The Usability Test (Week 13): A naive user from another team will attempt to install and run your tool using only your README.md. You must watch them struggle in silence. You are not allowed to help them. This is the ultimate test of your documentation.

Last updated on