Every CYF session begins with an energiser. Usually there’s a rota showing who will lead the energiser. We have some CYF favourite games you can play if you are stuck.

Traffic Jam: re-order the cars to unblock yourself
Telephone: draw the words and write the pictures
Popcorn show and tell: popcorn around the room and show one nearby object or something in your pocket or bag and explain what it means to you.

Learning Objectives

Introduce and welcome new volunteers
Nominate a timekeeper
Check the morning day plan and group structures

Planning during the week

🧭 During the week, create a post on Slack and get some people to take on the roles of facilitator and timekeeper. Nominate new people each time.

👣 Steps

If you haven’t done so already, choose someone (volunteer or trainee) to be the facilitator for this morning orientation block. Choose another to be the timekeeper.

🎙️ The Facilitator will:

Assemble the entire group (all volunteers & all trainees) in a circle
Briefly welcome everyone with an announcement, like this:
💬 “Morning everyone, Welcome to CYF {REGION}, this week we are working on {MODULE} {SPRINT} and we’re currently working on {SUMMARISE THE TOPICS OF THE WEEK}”
Ask any newcomers to introduce themselves to the group, and welcome them.
Now check: is it the start of a new module? Is it sprint 1? If so, read out the success criteria for the new module.
Next go through the morning day plan only (typically on the curriculum website) - and check the following things:

Facilitator Checklist

Check the number of volunteers you have for the morning
Check someone is leading each session
Describe how any new activities works for the group
Decide how best to allocate trainees and volunteers for a given block - most blocks will make this clear

⏰ The Timekeeper will:

Announce the start of an activity and how long it will take (check everyone is listening)
Manage any whole class timers that are used in an activity
Give people a 10-minute wrap-up warning before the end of an activity
Announce the end of an activity and what happens next

Learning Objectives

Identify features for a product
Write user stories for a product
Explain the importance of reading and understanding the acceptance criteria

Preparation

Post-its and a collaborative board.

Introduction

When mapping a product, we go from the high to the lowest level to plan our delivery. The reason for that is so that the team and stakeholders all have the same knowledge of the strategy of the product and the main end goal.

However, we cannot deliver everything at once. And we also cannot plan every detail. We can prioritise the must-haves and then focus on them.

Product > Features > User Stories > Tasks

This mapping process is also sometimes called User Journey mapping or Story Mapping. And you can - and should - do it whenever you are starting a new project.

What questions should we ask to identify what needs to be built?

🎯 Goal: To understand the requirements of building a library website. (5 minutes)

Let’s assume we have been asked to build a library website that allows you to borrow books.

Discuss briefly as a class what questions we should ask to understand better what we will build.
Write these questions on post-its and share them on the collaborative board.

Make sure to encourage different people to share their ideas

Focus is on the questions, not the answers!

What features should this website have?

🎯 Goal: To understand the process of breaking down a product into features. (10 minutes)

Let’s assume we got answers to all our questions about the product. (We are not going to actually answer them)

Overall, the goal is to build a website with a catalogue of books that can be borrowed online.

In small groups, identify the main features you would expect to see on this website. In this example, features could be a shopping cart, book search, etc.
One person of each group to share the group’s thoughts with the class.

Breaking features down into user stories

🎯 Goal: To understand the process of breaking down features into user stories. (15 minutes)

Now that we have all the features, we need to break them down into user stories.

In small groups, pick one of the features and break it down into at least 2 user stories. For example, for the shopping cart feature the user stories could be:

As a library user, I want to be able to remove items I have included in my shopping cart so that when I checkout the remaining books are the ones I want to borrow.
As a library user, I want to be able to pay with credit card for the books in my shopping cart so they can be delivered to me

Different group representatives volunteer to share thoughts with the class.

Tasks needed to deliver this user story

🎯 Goal: To understand the process of breaking down user stories into tasks and distributing those tasks among team members. (15 minutes)

Now that we have user stories, it is time to break them down into tasks. Tasks are used to break down user stories into smaller components that can then be assigned to individual team members.

Chose a user story and in the same groups complete the following:

Identify the tasks that need to be completed in order to deliver value to the user, providing the outcome described in the user story.
Identify relationships and dependencies between tasks.
- How does a change in Task A affect other tasks?
- Does Task A need to be completed before we can work on Task B?
Size those tasks taking into account complexity and dependencies.
Answer these questions: when is it the right time to assign tasks to team members, what would be the criteria you would follow when assigning tasks?

Examples of tasks for a user story describing the book search functionality could be Search Box, Text Autocomplete, Database creation and setup. Discuss in small groups.

Again, a different group representative volunteer to share thoughts with the class.

A quick break of fifteen minutes so we can all concentrate on the next piece of work.

Learning Objectives

Identify areas of weakness
Address misconceptions from prep work
Step through some code and check how it runs

This is a pairing activity!

Each pair will need to split into navigator and driver.
Volunteers can pair up too - they need to drive though!
Navigators you can read the instructions for this workshop as you get setup

This activity will consist of the following steps:

🧑‍💻 Predict ➡️ Explain

Given a program or piece of code, you’ll have to explain what the code currently does. Not what it should do.

🔍🐛 Find the bug

Given a target output/behaviour - trainees can identify a bug in the source code

🪜🧭 Propose a strategy

Given a problem, you’ll have to think about a strategy for solving it. This doesn’t involve coding but stepping back to think about how you could solve the problem. You might want to talk aloud, draw a flow diagram or write out the steps you’d take in your solution.

For the specific task, check with the facilitator on Saturday.

Learning Objectives

Perform quick temperature check on the current concepts
Devise strategies for dealing with misconceptions during the week

Assemble as group
Briefly discuss any particular areas of concern following the diagnose block
Devise strategies for addressing misconceptions

🛎️ Code waiting for review 🔗

Below are trainee coursework Pull Requests that need to be reviewed by volunteers.

NW-6 | Fikret Ellek | JS3| [TECH ED] Array Destructuring | WEEK-3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

NW-6 | Fikret Ellek | JS3| [TECH ED] Programmer Humour | WEEK-3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

NW-6 | AREEB-SATTAR | JS3| [TECH ED] Programmer Humour | WEEK-3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

NW6 | Hadika Malik | JS3 | Programmer humour | Week - 3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.
Completed the fetch and rendered the image

Questions

Ask any questions you have for your reviewer.

Start a review

NW-6 | AREEB-SATTAR | JS3| [TECH ED] Array Destructuring | WEEK-3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

See more pull requests

Every Saturday at CYF we cook and eat together. We share our food and our stories. We learn about each other and the world. We build community.

This is everyone’s responsibility, so help with what is needed to make this happen, for example, organising the food, setting up the table, washing up, tidying up, etc. You can do something different every week. You don’t need to be constantly responsible for the same task.

Debugging is Asking Questions

Prep

Re-read this article about Mental Models
Watch this video about VSCode Debugger and follow along with the mini-workshop
Open this CYF Workshops repo in VSCode and go to the debugging/bank folder to find the problem bank.

Whew, that’s loads! But we did set it all as coursework, so you have done it already, right? 😉

Today we’re going to use our formal language of developer questions. We began with this basic format:

What I did
What I expected
What actually happened

This format helps to find the discrepancies between expectations and reality. (This is the gap in our understanding.)

It really helps us with debugging. Today we will use a debugger and our scientific method to find and fix bugs. Recall your scientific method:

Recap asking questions

Predict & Explain

Make a prediction by explaining what the outcome will be

Test

Run the code to see what actually happens

Compare and Update

Compare the outcome with our prediction
Explain the gap between our prediction and what actually happened
Update our understanding

This process is cyclical.

graph LR
A[Predict]
B[Explain]
C[Test]
D[Compare]
E[Update]
A --> B
B --> C
C --> D
D --> E
E --> A

Setup

Get into pairs. Each pair consists of two roles:

Computer: Execute the code mentally, predicting the outcome.
Debugger: Use the VSCode debugger to step through the code.

You will swap roles after each exercise.

Set a whole class timer for 10 minutes.

Stepping

Understanding Variables and Flow, 10m

Identify the value of variables at each step in a loop.

const sumArray = (numbers) => {
  let total = 0;
  for (let i = 0; i < numbers.length; i++) {
    total += numbers[i];
  }
  return total;
};
console.log(sumArray([1, 2, 3]));

Computer:

Write down predictions for total and i values before each loop iteration.
Compare predictions after each Debugger’s step.

Debugger:

Open sumArray.js in VSCode.
Choose ‘Run > Start Debugging’ from the menu.
Set a breakpoint at total += numbers[i];.
Step into your function.
Step Over through iteration until your loop is complete.
Monitor total and i in the Variables section.

Debugging

Okay, swap roles. Set a whole class timer for 15 minutes.

Finding an Error, 15m

const findLargest = (numbers) => {
  let largest = numbers[0];
  for (let i = 1; i < numbers.length; i++) {
    if (numbers[i] > largest) {
      largest = numbers[i];
    }
  }
  return largest;
};
console.log(findLargest([3, 7, 2, 5, 6]));

Debugger:

Open findLargest in VSCode.
Predict the return value of findLargest. Write your prediction down.
Set a breakpoint at if (numbers[i] > largest).
Debug and inspect i, numbers[i], and largest.
Write down the return value of findLargest([3, 7, 2, 5, 6]).

Computer:

Predict the value of largest after each loop iteration.
‘Execute’ the code and write down the actual value of largest after each loop iteration.
Write down the return value of findLargest([3, 7, 2, 5, 6]).
Now execute the code in VSCode. Did you get the same result?

Both (briefly) write up your mental model using this format:

What I did
What I expected. Make sure you include your prediction here
What actually happened

Okay, swap roles. If you have time left and you’re into this, there are many problems stored in debugging/bank. Set a whole class timer for 15 minutes.

Problem Bank, 30m

Pick any problem from the bank and work through it together. Use the debugger and the scientific method to find and fix the bug.

Write up your findings in the developer question format. Swap roles and repeat until we run out of time.

🧑🏾‍💻🙋 Developer questions contain

🔗 Links 👍
Objectives - what are you actually trying to do? 👍
🖼️ Screenshots of UI 👍
📝 Code blocks 👍
📷 ~~Screenshots of code~~ 🙅

📚 Further reading

What are we doing now?

You’re going to use this time to work through coursework. Your cohort will collectively self-organise to work through the coursework together in your own way. Sort yourselves into groups that work for you.

Use this time wisely

You will have study time in almost every class day. Don’t waste it. Use it to:

work through the coursework
ask questions and get unblocked
give and receive code review
work on your portfolio
develop your own projects

Please feel comfortable and welcome to pray at this time if this is part of your religion.

If you are breastfeeding and would like a private space, please let us know.

What are we doing now?

You’re going to use this time to work through coursework. Your cohort will collectively self-organise to work through the coursework together in your own way. Sort yourselves into groups that work for you.

Use this time wisely

You will have study time in almost every class day. Don’t waste it. Use it to:

work through the coursework
ask questions and get unblocked
give and receive code review
work on your portfolio
develop your own projects

🛎️ Code waiting for review 🔗

Below are trainee coursework Pull Requests that need to be reviewed by volunteers.

NW-6 | Fikret Ellek | JS3| [TECH ED] Array Destructuring | WEEK-3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

NW-6 | Fikret Ellek | JS3| [TECH ED] Programmer Humour | WEEK-3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

NW-6 | AREEB-SATTAR | JS3| [TECH ED] Programmer Humour | WEEK-3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

NW6 | Hadika Malik | JS3 | Programmer humour | Week - 3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.
Completed the fetch and rendered the image

Questions

Ask any questions you have for your reviewer.

Start a review

NW-6 | AREEB-SATTAR | JS3| [TECH ED] Array Destructuring | WEEK-3 🔗

Learners, PR Template

Self checklist

I have committed my files one by one, on purpose, and for a reason
I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
I have tested my changes
My changes follow the style guide
My changes meet the requirements of this task

Changelist

Briefly explain your PR.

Questions

Ask any questions you have for your reviewer.

Start a review

See more pull requests

Retro (20 minutes)

A retro is a chance to reflect on this past sprint. You can do this on a Jamboard (make sure someone clicks “Make a copy” before you start, and you work on that together) or on sticky notes on a wall.

Set a timer for 5 minutes.
Write down as many things as you can think of that you’d like to start, stop, and continue doing next sprint.
Write one point per note and keep it short.
When the timer goes off, one person should set a timer for 1 minute and group the notes into themes.
Next, set a timer for 2 minutes and all vote on the most important themes by adding a dot or a +1 to the note.
Finally, set a timer for 8 minutes and all discuss the top three themes.