Ship Better Code, Faster

Appearance

Workshop 1: Slide Content ​

Deck: slides.pptx (28 slides, ~60 min) — published: Google SlidesTheme: Software Delivery Lifecycle & Baseline Measurement

Each section below = one slide. The OAF template layout for each slide is noted in brackets. If you edit a slide, update both the .pptx and this file so they stay in sync.

Slide 1: Title [lavender title slide] ​

Wordmark (top): The Build Fellowship Title: Measuring software delivery. Eyebrow: Session 1

Slide 2: Welcome [white, headline + body] ​

Title: Welcome! Subtitle: What these eight weeks are Body: For the next eight weeks we will step into the shoes of a Platform Engineer at a real software company. We will measure things. We will break things. We will ship better. By the end you will have a portfolio-ready project that proves you can move an engineering team forward.

Slide 3: Agenda [dark blue, agenda layout] ​

Title: Agenda Bullets (5):

  • 15 min: Introductions & my path into platform engineering
  • 5 min: How the workshops work + expectations
  • 15 min: The software delivery lifecycle and why companies hire for it
  • 10 min: Clone the OrbitTasks repo onto your machine
  • 15 min: Measure the current pipeline, your first deliverable

Slide 4: About me [white, 2-column] ​

Title: Hi, I'm Riain. / Your guide for the next 8 weeks. Left subhead: What I do Left body: Platform Engineer at PermitFlow. Background: Lead Platform Engineer @ Personio, SWE + Architect @ Aviva Ireland, Computer Science @ Dublin City University. I've worked across backend, platform tooling, and AI-assisted engineering. Spent the last few years caring about how teams ship, not just what they ship. Right subhead: Where to ask me anything Right body: You should ask me about: why platform, what the difference between "product" and "platform" really feels like, or how to talk about your work in an interview, career growth etc. You can reach me via email. I also love skiing and theatre, where I work internationally on site-specific work.

Slide 5: Quick check-in [dark, title + body + bullets] ​

Title: Your turn, who are you? / Round-robin, 60 seconds each. Body: Pick any two of the prompts below and share with the group. We'll go in the order Zoom shows you. Bullets (4):

  • Your name, school, and what you're studying
  • Why you applied to this project specifically
  • A piece of software you wish was less frustrating
  • One thing you want to walk out of these 8 weeks with

Slide 6: Section divider [dark blue] ​

Big text: How these / eight weeks work

Slide 7: The 8-week arc [white, title + body + bullets] ​

Title: From measuring the problem / to proposing the fix. Body: Every week you deliver one piece of a single, growing engineering proposal. By week 8 you've made the case end-to-end. Each week builds on the last. Here's the shape of the arc. Bullets (4):

  • Weeks 1–2: Measure the current pipeline and find the bottlenecks.
  • Weeks 3–4: Build a real CI/CD pipeline and improve developer experience.
  • Weeks 5–6: Use AI coding tools well, then prove the improvements with metrics.
  • Weeks 7–8: Set engineering standards and present the whole thing to stakeholders.

Slide 8: Working norms [lavender, 2-col] ​

Title: How we work / together for 8 weeks. Left subhead: Cameras on, ask anything Left body: These workshops are interactive. I want to see your faces and I want you to see each other. Use chat or unmute. If you're stuck on setup, you're probably not alone, so speak up early. Right subhead: We do the work together in session Right body: The core work happens live, together, in the hour. You don't take it home. Outside of session, expect up to 2 hours a week of optional polish or reading, never required to keep up. Workshop time is where the work gets done; everything else is bonus.

Slide 9: The deliverable [white, 2-col numbered] ​

Title: What is the deliverable? 01. The Repo: Over the next eight weeks we will remediate many issues in a sample repo, of which you'll have your own copy to work on. By the end of our time together, you'll (hopefully) have a much more performant repo. 02. The Presentation: For the final workshop, you'll be asked to put together a presentation for stakeholders (me) where you'll utilise all of your learnings and findings to illustrate the impact of your work.

Slide 10: Coursework + the app's site [white, 2-col numbered] ​

Title: Coursework + the app's site 01. Coursework Plans: Access all plans and detailed information at: https://tbf-coursework.riaincondon.com — this may be most helpful post completion of this course.02. Live Site & Code: Explore the live site and app codebase at: https://tbf.riaincondon.com and https://github.com/riain0/tbf-orbittasks — login information can be found in the README.md.

Slide 11: Section divider [dark blue] ​

Big text: The software / delivery lifecycle

Slide 12: What is the SDLC [white, headline + body] ​

Title: What is the Software Delivery Lifecycle? Subtitle: One sentence definition Body: The full path a single line of code takes from the moment an engineer writes it on their laptop to the moment a customer feels the result. A bottleneck anywhere along this path slows down the whole team, not just the engineer who wrote the code.

Slide 13: The lifecycle stages [white, title + body + icon bullets] ​

Title: Code → Customer: The Lifecycle Stages Body: Every stage can become a bottleneck, and today we measure all of them. Bullets (4, material icons):

  • [code] Code + Review: an engineer writes a change and a peer signs off on it.
  • [build] Build: the codebase compiles into runnable artifacts.
  • [fact_check] Test: automated checks run against the build to ensure quality.
  • [rocket_launch] Deploy + Monitor: ship to customers and watch how it behaves in production.

Slide 14: Where time goes [white, headline + body] ​

Title: Where engineering time goes Subtitle: What the data shows Body: Across studies from DORA, SPACE, and Stripe's "Developer Coefficient" report, the pattern is consistent: engineers spend roughly half of every working hour fighting their own tools. Waiting on CI, setting up environments, investigating flaky tests, and reviewing PRs eat into the time available for actually writing code. For every hour writing code, engineers spend about an hour on toil. That's the problem this series is about.

Slide 15: Careers [dark, title + body + icon bullets] ​

Title: Who gets paid to do this work? Body: The skills you'll build over these eight weeks map directly to three well-paid engineering roles. The work overlaps heavily, but the core focus differs. Bullets (4, material icons):

  • [settings] DevOps Engineer: owns pipelines, deployment infra, and monitoring.
  • [layers] Platform Engineer: builds the internal product other engineers use to ship.
  • [speed] Site Reliability Engineer (SRE): keeps the system up, defines SLOs, runs incident response.
  • All three start with the same question: where is engineering time being lost?

Slide 16: Industry examples [dark, title + body + bullets] ​

Title: A look behind / the curtain. Body: Four real engineering organizations, ordered from extreme to typical. Bullets (4):

  • Netflix: 4,000+ deploys per day. Every engineer can ship to prod safely.
  • Stripe: ~10 minutes from commit to production. Internal tools are a first-class product.
  • Shopify: their internal "Spin" platform boots a full dev env in under a minute.
  • OrbitTasks: a ~13-minute CI, flaky tests, toil.

Slide 17: Section divider [dark blue] ​

Big text: Meet / OrbitTasks

Slide 18: OrbitTasks situation [dark, title + stat blocks] ​

Title: OrbitTasks: the situation. Body: 28-person Series A startup. Project management SaaS. The pipeline is buckling. Stats (4):

  • ~13 minutes: CI pipeline duration on every PR. ~95% is one stage. You feel every run.
  • ~30% Failure Rate: share of test runs that fail for non-deterministic reasons.
  • 2 Days Onboarding: the time it currently takes to get a new engineer fully set up.
  • The Mission — You: the platform engineer hired to fix all of these critical issues.

Slide 19: Tool installation [white, 2-col] ​

Title: Tool installation Body: Follow the instructions below for your operating system to get your environment ready. Left (macOS & Linux):

  • Node & npm: use nvm (Node Version Manager). Run the install script from nvm.sh then nvm install 24.
  • Git: macOS usually has it. If not, brew install git. Linux: sudo apt install git-all. Right (Windows):
  • Node & npm: download the v24.x.x LTS installer (.msi) directly from nodejs.org.
  • Git: download and run the "Git for Windows" installer from git-scm.com. Use the default settings.
  • Terminal: use PowerShell or Git Bash for the best experience.

Slide 20: Verify your env [white, title + body + bullets] ​

Title: Step 0: Verify your environment. Body: Run the four commands below to ensure your local machine is ready for the project. If any command produces errors, say so now. Fixing setup live is part of the work. Bullets:

  • node --version: v24.x.x or newer.
  • npm --version: v10.x.x or newer.
  • git --version: any 2.x release is fine.
  • macOS/Linux ls (Windows dir): should show apps/, scripts/, package.json at the project root.

Slide 21: Clone the repo [white, 2-col] ​

Title: Step 1: clone OrbitTasks locally. Left subhead: Run these commands Left body: git clone https://github.com/riain0/tbf-orbittasks.git, then cd orbittasks, then npm install. Right subhead: If something breaks Right body: Drop the error message in chat. We will troubleshoot live; this is part of the work, not an interruption. If your machine is too constrained, pair with a neighbor and we'll get you set up afterward.

⚠️ Deck bug: the clone creates a directory named tbf-orbittasks, but the slide says cd orbittasks. Either fix the slide to cd tbf-orbittasks, or say it aloud in session. (Alternative: tell students git clone <url> orbittasks to match the slide.)

Slide 22: Section divider [dark blue] ​

Big text: Establish / the baseline

Slide 23: Measurement plan [white, title + body + bullets] ​

Title: Three numbers / that matter today. Body: Numbers without observations are noise. Observations without numbers are opinions. We want both. Capture all three categories below as you run the pipeline. Bullets (4):

    1. Wall-clock time: how long from "I push" to "this stage finishes."
    1. Pass / fail: did the stage complete cleanly? What was the visible error?
    1. Observations: anything that felt slow, redundant, or confusing. Gut reactions count.
  • We record all of this in your course logbook as we go. We reuse this data in Session 2.

Slide 24: Pipeline stages [white, numbered grid] ​

Title: Eight stages, one row each Subtitle: Or: run npm run ci to do all eight in one go Body:

    1. install: npm install (~7–90s)
    1. lint: npm run lint (~2s)
    1. typecheck: npm run typecheck (~2–3s)
    1. test:api: npm run test --workspace=apps/api (~12 min)
    1. test:web: npm run test --workspace=apps/web (~2–10s)
    1. build:api / web: npm run build --workspace=apps/... (~1s each)
    1. deploy: npm run deploy (~18s)
    1. Logbook & Automation: wrapper script writes timing to baseline.log automatically.

Slide 25: Hands-on [white, title + numbered steps] ​

Title: Run it. Watch it. Write it down. Body: We run npm run ci at the repo root. It takes ~13 mins (mostly test:api). We capture observations in your logbook as it runs. Steps (4):

    1. Open: open your terminal at the project root.
    1. Run: run npm run ci. It writes to baseline.log.
    1. Capture: fill the W1 logbook section. Note what surprises you.
    1. Log: fails are data. Write down what failed and how.

Slide 26: Capture observations [dark, 2-col] ​

Title: What goes in / your logbook. Left subhead: Numbers Left body: Duration of each stage. Total wall-clock time end to end. Pass or fail per stage. How long npm install spent fetching versus actually installing. Right subhead: Observations Right body: Which stage felt slowest? Did any test fail, and was it repeatable? Anything that confused you or looked redundant? Gut reactions go here.

Slide 27: Session 2 preview [white, title + body + icon bullets] ​

Eyebrow: NEXT SESSION PREVIEW Title: Profiling and Root Cause Diagnosis. Body: We'll pick up the data you just logged and tear it apart together. Three things we'll cover next time: Bullets (4, material icons):

  • [analytics] Profiling techniques: finding the actual hot path in a pipeline, not just the obvious one.
  • [account_tree] 5 Whys & Fishbone: industry frameworks for getting past symptoms to root cause.
  • [low_priority] Prioritization: which bottlenecks are worth fixing first, by impact and effort.
  • [menu_book] Keep your logbook; we reuse today's baseline numbers next week.

Slide 28: Questions [dark blue, Big Stat layout] ​

Big text: Questions?