Appearance
Session 1: Facilitator Notes
Session: Software Delivery Lifecycle & Baseline Measurement Duration: 60 minutes Facilitator: Riain Condon (me) Deliverable for students: Annotated workflow diagram with baseline timing measurements for each pipeline stage.
Before the session
Run through this checklist 24–48 hours before:
- Repo URL is live, public, and clone-able from a fresh machine.
- I have personally run
npm install && npm run cion the released commit in the last week, andbaseline.loglooked sensible. - I have a backup copy of the timing log to share if a student's local run fails.
- Slack/Zoom chat is open with the repo URL ready to paste at minute 30.
- My camera, mic, and screen-share are working.
- The handout and the course logbook link are pinned where students can grab them (Notion, Drive, or pinned in chat).
- I have personalized slide 4 (my bio); strip the brackets.
If any of the above is unchecked, I fix it before going live.
Time budget (60 minutes total)
| Block | Mins | Slides |
|---|---|---|
| 1. Introductions & my story | 15 | 1–5 |
| 2. Workshop layout & expectations | 5 | 6–8 |
| 3. SDLC + career relevance | 15 | 9–14 |
| 4. Clone the repo | 10 | 15–18 |
| 5. Baseline measurement exercise | 15 | 19–25 |
Drift more than 3 minutes on any block and skip something in the next one. Do not steal time from block 5; that's the deliverable.
Block 1: Introductions (15 min)
Slides 1–2 (~2 min)
Welcome them in warmly. Don't read the slide. The first 30 seconds set the tone for 8 weeks: be calm, be glad they're here.
"Welcome. For the next eight weeks we are going to step into the shoes of a platform engineer at a small startup that is drowning in its own pipeline. Today we measure how bad it actually is."
Slide 3 (~1 min)
Quick orientation to the hour. Don't dwell. Students don't need to memorize the agenda; they need to know I have a plan.
Slide 4 (~5 min, MY story)
This is the most important slide of the whole 8 weeks. The fellowship works because students see themselves in my path. I talk about:
- Where I started (school, first job, first big mistake).
- How I ended up doing platform / DevEx work specifically. Was it intentional? An accident?
- What changed about the way I think about software once I started caring about how it gets shipped.
- One concrete moment that shaped my career: a deploy that went wrong, a manager who pushed me, a tool I built that other engineers actually used.
Avoid: linear resume narration ("then I joined X, then Y, then Z"). Hit two or three vivid moments instead.
Slide 5 (~7 min, student introductions)
Hard limit ~45 seconds per student. If I have 7 students, that's about 5–6 minutes; pad to 7. Read the prompt out loud once, then pick the first person by Zoom layout and let it flow.
Watch for: quiet students, English-as-second-language students. Pull them in gently ("Maria, you're next, take your time"). Don't let one person take 2 minutes.
Block 2: Workshop layout (5 min)
Slide 6
Section divider. Don't speak to it; it's just a beat.
Slide 7 (~3 min)
Walk left to right. Don't oversell, just lay out the arc. Two anchor points:
- Week 1 (today) is highlighted because we measure the problem.
- Week 8 is the stakeholder presentation; flag it now so students think about it from day one.
If anyone asks "what if I miss a week," tell them: we do the core work together live, so the way to catch up is to come to session. Every session builds on the previous one's logbook entries. Catching up is doable but not free. Encourage them to message me before they miss.
Slide 8 (~2 min)
Norms. Read them, but pause on "ask anything." That one matters.
"If you are stuck on setup, you are probably not the only one. Speak up early. Silent frustration is the only failure mode of this program."
Block 3: SDLC + careers (15 min)
Slide 9
Section divider. Don't speak.
Slide 10 (~2 min)
The definition is one sentence. Read it. Then immediately ground it in a concrete story:
"Last Tuesday I changed one line of code at work. That one line went through eight different systems before a customer saw it. The fact that it took 14 minutes from my push to the deploy finishing was... fine. It used to take an hour. Someone fixed that. That someone got promoted."
The three reasons below are not bullet points to read. Use them as expansion points if a student asks "why does this matter."
Slide 11 (~4 min)
The 6 stages. Walk through each one in 30 seconds:
- Code: what an engineer does on their laptop.
- Review: peer review. Where social dynamics enter the pipeline. Often a hidden bottleneck.
- Build: compile, bundle, package. Pure mechanics. Easiest to optimize.
- Test: automated checks. Where flakiness lives.
- Deploy: push to where customers can reach it. Where risk concentrates.
- Monitor: watch in production. Feeds back into the next change.
Point at the arrow between "Monitor" and a metaphorical "next code": the loop is the point.
Slide 12 (~3 min)
This chart sets up the rest of the program. The takeaway is the line in the box:
"For every hour engineers spend writing code, they spend about an hour fighting their tools."
Ask the room: "Have any of you experienced this in any context, not even just software? Waiting on a build, waiting on a teacher to grade, waiting on a process to finish so you can start?" Get one or two answers.
Slide 13 (~3 min)
Three roles. The point isn't memorization; it's salary anchoring. Students are going to school partly because they want a career. Show them that the skills they will build in this fellowship map to real, well-paid roles.
If a student asks "do I need a degree for these?", honest answer: not strictly, but the realistic path for a student through these roles usually starts with a CS or adjacent degree, then internships, then the work itself. The skills matter more than the credential for the work; the credential opens the door.
Slide 14 (~3 min)
Industry examples. The point is contrast:
- Netflix and Stripe represent the upper bound of what's possible.
- The last card ("a typical 50-person startup") is OrbitTasks, the case study.
- Don't lionize Netflix. Most students will join companies that look like OrbitTasks, not Netflix. The skills are the same, but the scale is different.
Block 4: Clone the repo (10 min)
Slide 15
Section divider. Don't speak.
Slide 16 (~2 min)
Lay out the case study. Read the four stats, let the "You" land. It should feel like I'm recruiting them for a role, because I am.
Slide 17 (~6 min, hands-on)
Drop the actual repo URL in chat now.
Then walk through the commands one at a time. Wait for nods or chat confirmations after each. The pace should be:
- Paste URL → ask everyone to copy.
git clone→ wait for at least 3 students to confirm "done in chat."cd orbittasks.node --version→ if anyone is on Node 18 or lower, ask them to install nvm and switch.npm install→ this takes 30–90 seconds. Let it run while I do slide 18.
Most common breakages and the fix:
| Symptom | Fix |
|---|---|
git: command not found | Install git (link in chat: brew/apt). |
| Permission denied (publickey) | Use the HTTPS clone URL, not SSH. |
node: command not found or wrong version | Install nvm + Node 20. Share nvm install 20 && nvm use 20. |
npm install fails on better-sqlite3 build | Usually missing build tools. On macOS, xcode-select --install. On Linux, apt install build-essential. |
| Corporate network blocks npm registry | Have student switch to personal hotspot. Skip the install; they can pair-program with a neighbor for today. |
npm start fails to boot the app | Expected; that's the Week 4 lesson. Don't fix it live; just note it. |
Don't move on until at least 80% of students are unblocked. If 1–2 are still stuck, pair them with someone who's working and continue.
Slide 18 (~2 min)
The verification table. Run through it as a checklist. If anyone is missing a row, surface it now, not later.
Block 5: Baseline measurement (15 min)
This is the deliverable. Protect this block.
Slide 19
Section divider. Don't speak.
Slide 20 (~2 min)
Three things to capture. Read them. Hammer this line:
"Numbers without observations are noise. Observations without numbers are opinions."
Slide 21 (~2 min)
Show them the stages we'll time. Point out that they can run each manually, OR use the wrapper script. Recommend the wrapper: it writes baseline.log for them and removes one piece of friction.
Slide 22 (~8 min, hands-on, we do this together)
The actual exercise. We run it together, live; I share my screen and students mirror in their own clones.
What I do during this block:
Open the handout and the course logbook in my share so students can see both. Tell them: we fill the W1 logbook section together as we go.
We all start
npm run citogether.Set a timer for 7 minutes.
As
ciruns on their machines, narrate the real bottleneck out loud:"Install and lint fly by in seconds. Then
test:apistarts, and it just sits there, for something like twelve minutes. That one stage is ~95% of the whole pipeline. That's the thing we're here to understand."As students see the test suite, narrate the slow test:
"Take a look at
reports.test.tsand the wholetests/integration/suite. There's no sleep anywhere; it makes dozens of real HTTP round-trips to the mock server, one at a time. The billing rollup alone enrolls and charges 25 users, ~50 real calls. Why is it so slow? Hold that thought for Session 2."As students see the flaky test, ask: "Did anyone's tests fail? Run it again. Did the same test fail?" Get them to notice the non-determinism. Don't explain it yet.
Expected: test:api and/or test:web will report FAIL on roughly half of runs because of the five documented flaky tests. This is expected, not a broken clone. Have students record the FAIL as data and move on; re-running flips it.
If a student's machine is too slow and npm run ci won't finish in 7 minutes: share my own baseline.log; they can use it for today's deliverable and run their own afterward.
Slide 23 (~2 min)
Now we fill the W1 logbook section together. Walk through it on screen and have students fill theirs as we go. Confirm everyone has captured:
- The per-stage timings.
- A 2–3 sentence observation paragraph at the end.
Tell them to ping in chat when their W1 logbook section is filled. Mark down who's done. If a student wants to polish their notes afterward, that's optional.
Slide 24 (~1 min)
Preview Session 2 briefly. Frame it as continuity, not homework: keep your logbook current; we reuse today's baseline numbers next week, in Workshop 6, and in Workshop 8.
Slide 25 (~remaining time)
Open Q&A. If nothing comes, prompt them:
- "Any of the careers I showed earlier feel like they fit you?"
- "Anything that didn't make sense? Say so now while it's fresh."
- "Anyone want to share a number they got that surprised them?"
End on time. Going long on session 1 is a tax on every other session.
Anticipated student questions & answers
"Why does this pipeline exist? Why don't they just deploy it manually?"
They used to. As the team grew, manual deploys started causing outages. CI/CD is the cost of being able to ship safely with more than ~5 engineers.
"Is this an actual company?"
No. OrbitTasks is fictional, but every pain point in this codebase comes from a real engineering team. We use a fictional company so we can change the code without consequences.
"Will I get a job in DevOps after this fellowship?"
The fellowship is one input. The portfolio you'll build here is real and you can talk about it in interviews. Most people who do this work spend a few years in adjacent roles (software engineering, infra, support) before specializing. The skills compound.
"Can I use AI tools for the optional polish?"
Yes, with eyes open. Session 5 is literally about how to use AI well and how to evaluate its output. For now: if you let AI do something for you, you should be able to explain what it did line by line.
"Why TypeScript and not Python?"
Because the JavaScript ecosystem is the largest in production software today, and the skills transfer to almost every other language. If you're a Python person you'll be reading TypeScript by Session 3; it's not a big leap.
If I run short on time
In priority order, cut from the bottom:
- Drop slide 24 (preview): students will see it next week anyway.
- Compress block 1 to 10 min: cut my bio to 3 minutes, student intros to 30 seconds each.
- Skip slide 12 (chart): say "trust me, this matters; we'll see the data ourselves in 20 minutes."
Never cut:
- The clone + verify (block 4).
- The hands-on
npm run ci(block 5, slide 22). - Filling the W1 logbook section together (slide 23).
If I finish early
Bonus prompts (any of these works):
- Ask a student to share their screen and walk through the
baseline.logline by line. - Ask the room to predict which stage will be the biggest win to optimize.
- Ask: "If you were the CTO, what would you measure that's not on this list?"
Post-session checklist
- Post a recap message in the channel: "Today we did X together. Next week we'll do Y. Keep your logbook current; we reuse today's baseline numbers later."
- Note any students who were silent or struggling, and reach out to them privately.
- Capture any pain points I saw (a step that confused everyone, a tool that broke) in my journal; they shape Session 2 and beyond.
- If anyone couldn't clone or install, follow up over chat that evening so they're not blocked at the start of Session 2.