🧑🏾‍🤝‍🧑🏾 day-plan

✍🏽 Register

🎡 Morning orientation

Learning Objectives

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:

  1. Assemble the entire group (all volunteers & all trainees) in a circle
  2. 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}”

  3. Ask any newcomers to introduce themselves to the group, and welcome them.
  4. 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.
  5. 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

Introduce Yourself!

Learning Objectives

Activity

In your professional life, you will often be asked to introduce yourself. It is a good idea to have an elevator pitch ready, a brief (30 seconds) way of introducing yourself, getting across a key point or two, and making a connection with someone.

Today we will be going around the room and introducing ourselves! `

Facilitator(s) start by sharing your elevator pitch and then popcorn around the room.

Some tips:

  • Your response should be around 30 seconds. Think: What do you do? What are your skills, passions, or hobbies? What motivates you?
  • Have a list of items ready but tailor what you say to your audience. For example, at a technical conference focus on your technical interests rather than your love of making cupcakes, but on the first day of a new job introducing yourself to your new team, add 1-2 personal details.
  • Structure your response: Who are you? Where are you from? Where have you worked? Have you studied somewhere and what subjects?
  • Try to be enthusiastic, let your personality and confidence shine
  • Allow space for follow-up questions
  • It will feel awkward and nerve-wracking the first couple of times, practice-practice-practice to feel confident

Facilitator Check-in questions

  • How did you feel about public speaking?
  • What are some strategies to feel more confident when public speaking?
  • What activities could you share to create a connection? Ex. Sports, Hobbies

Workshop:Playing Computer 🔗

Learning Objectives

🎮 Playing computer

💡 Purpose

This workshop is designed to develop your understanding of playing computer. Playing computer means simulating how the computer executes our code. We “step through” the code, line by line, and work out what the computer does when it follows each instruction. Once we develop a better intuition for how our code runs it becomes easier to debug code, reason about it and write more complex programs.

During this session, you will:

Resources

You will need:

  • A piece of paper saying “memory” - where we store variables
  • A piece of paper saying “console” - where we print to the console
  • Some example programs like the ones here 👉 Playing computer workshop
  • [Optional] A set of functions in envelopes ( this isn’t essential but a nice thing to have to reinforce the idea of instructions being “opened” up when a function is called )

( If you don’t have any paper/pens you can create plain text files for “memory” and “console” and write your work out in there! )

🧰 Setup

  1. Split up into groups of 2 or 3 at most.
  2. Start with the first example ( e.g. example-0.js )
  3. Each person will need to take responsibility for a particular frame. One person will be assigned the role of global frame, for example. If there are other function declarations, someone else will “play” that frame too.

🍲 Warm-up

Start with the program in example-0.js. There is only one frame to play here - the global frame, as there are no other function declarations and calls in the file.

  • One person will “play” the Global frame
  • This person will step through the code in example-0.js using the rules of execution below.
  • Other members of the group can watch and provide support as they go through the code.
  • Once you’ve finished you can change some of the values/variables and then someone else can play the global frame too
  • ❗ After you’ve finished playing computer with the program, you should check your memory sheet and console sheet by using the Python visualiser

Rules of execution

Rule 0

Only one person can be sat at the table at a time ( where we write to the memory sheet/console sheet)

Rule 1

Start reading code from top to bottom, one line at a time

Rule 2

Write and update variables in memory as you go along For example, if the program says:

let a = 32;

You would write down “a : 32” on your piece of paper saying “memory”

Rule 3

If a function is called the person “playing” this frame takes the seat and we jump to the instructions in that function, using Rules 1 and 2.

Rule 4

When a function returns or finishes execution this person leaves their seat and the previous person sits down again.

You may need to play computer like this a few times before you get used to this way of thinking about the code. Make sure you swap roles so others get the chance to play a particular frame.

📝 Check your understanding

Doing this activity by hand is a great way to start thinking about how your code runs. Once you’ve gone through this activity and played computer with pen and paper, you can check what you’ve got on your piece of paper by playing computer with the Python Tutor code visualiser

Community Lunch

Every Saturday 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.

Standup

It’s time to stand up. Split into groups of no more than 6 people.

Stand in a circle and share for no more than 60 seconds each:

  • 📛 your name
  • 💪🏽 What you worked on yesterday
  • 🛟 What issues are blocking you / What problems you encountered
  • 👷🏾 What you will work on today

After everyone has given an update, reflect on next steps together. Can you team up on shared blockers? Is someone working on something interesting that you want to know more about?

Study Group Development

Learning Objectives

This time is set aside for you to work together in small groups to make progress on your coursework and objectives. You should have brought at least one ticket from your backlog to work on and ideally have prepared at least one question to get mentor support on.

You can also choose to do structured activities to consolidate your objectives for this sprint. Your learning journey belongs to you. Think about what you need to do to achieve the objectives for this sprint and how you can use this time to work towards them.

If you are working on a Pull Request, this is a great time to get real time code review from your peers and mentors. Remember to use the GitHub interface to comment on the code and ask questions so your work can be tracked.

🗂️ Options

Optional structured activity: Pair Programming

Pair programming

Learning Objectives

  • Switch between driver and navigator roles after
  • The “driver” is the person typing on the keyboard, just thinking about what needs to be written
  • The “navigator” reviews what the driver is doing and is thinking about to write next
  • Don’t dominate - this is teamwork

⌛ Time’s up! Take a break! Make a cup of tea. Good job, partners!

Optional structured activity: Code Review

Mentored code review

Learning Objectives

Our learners get feedback on their work through code review. At work, colleagues review each others code to understand code, look for problems, and both share and learn better ways of doing things.

At CYF every learner should get code review on their work every week.

Live Code Review

Pair up a volunteer with one or more learners.

  • The volunteer will review a pull request, and talk out loud about what they’re looking for and doing.
  • The learner(s) will ask questions as they do.
Hints and tips
  1. How did you understand what the goal of the PR is? Reading the title and description, looking at the coursework exercises, etc.
  2. The uses of the different tabs in a PR: Conversation, Commits, Files changed.
  3. What made a PR easy or hard to review:
    1. Where unrelated files/lines changed?
    2. Was code consistently formatted? Did indentation help or hurt understanding?
  4. How did you review the code? Did you read top-to-bottom? Did you jump around into and out-of functions? Did you look at tests? Did you clone the code locally and try running it?

🛎️ Code waiting for review 🔗

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

Karla Grajales | Sprint-2 - Module-Structuring-and-Testing-Data | SPRINT 2 🔗

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

In this project, I learned how to use string methods by referring to the MDN documentation, how to set and manage variables, and how data flows within functions. I also learned how to invoke functions properly, debug issues to understand why something doesn’t work, perform operations on strings, and iterate through strings based on their length.

Questions

Ask any questions you have for your reviewer.

Start a review
Glasgow_Class|Shreef_Ibrahim|Structuring _Testing _Datast|Week2_exercise2_update 🔗

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
WM4 | Fatima Safana | Module-Structuring-and-Testing-Data | WEEK6 🔗

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
Glasgow_Class|Shreef_Ibrahim|Structuring _Testing _Datast|Week1_exercise1-update 🔗

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
CYF London | Rihanna Poursoltani | Module Structuring and Testing Data | Sprint 2 🔗

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

Afternoon Break

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.

Study Group Development

Learning Objectives

This time is set aside for you to work together in small groups to make progress on your coursework and objectives. You should have brought at least one ticket from your backlog to work on and ideally have prepared at least one question to get mentor support on.

You can also choose to do structured activities to consolidate your objectives for this sprint. Your learning journey belongs to you. Think about what you need to do to achieve the objectives for this sprint and how you can use this time to work towards them.

If you are working on a Pull Request, this is a great time to get real time code review from your peers and mentors. Remember to use the GitHub interface to comment on the code and ask questions so your work can be tracked.

🗂️ Options

Optional structured activity: Pomodoro

Pomodoro

Learning Objectives

Each group member, take a small-scoped piece of work from your backlog. Set a timer for . Use this focused time to complete your ticket and open a PR.

⌛ Time’s up! Take a break! Make a cup of tea. Walk around a bit.

Now set a new and review each PR as a group.

⌛ Time’s up! Take a break! Make a cup of tea. Stretch! Look at how much progress you made in one hour. ✨

Optional structured activity: Kata

Kata

Learning Objectives

The goal of a kata is to practice a specific skill, such as refactoring, or to learn a new language or framework.

Kata are often used in coding dojo, a practice where a group of programmers work together to solve a programming problem. Today we will use kata to practice TDD, using a simple kata from our Codewars collections.

TDD Pair Kata (20 minutes)

One person will be the driver. The driver can only write the code as directed by the navigator. One person will be the navigator. The navigator can only give directions to the driver. Hands off the keyboard!

The driver and navigator will solve the kata TDD style. First write a failing test, then write the code to make it pass. Then refactor the code. Write the simplest code that passes the test. Start with the simplest test, and work your way up to the most complex.

Retro: Start / Stop / Continue

  Retro (20 minutes)</span>

A retro is a chance to reflect. You can do this on RetroTool (create a free anonymous retro and share the link with the class) or on sticky notes on a wall.

  1. Set a timer for 5 minutes. There’s one on the RetroTool too.
  2. Write down as many things as you can think of that you’d like to start, stop, and continue doing next sprint.
  3. Write one point per note and keep it short.
  4. When the timer goes off, one person should set a timer for 1 minute and group the notes into themes.
  5. 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.
  6. Finally, set a timer for 8 minutes and all discuss the top three themes.