🧑🏾‍🤝‍🧑🏾 day-plan

🔖
  1. Morning orientation
  2. Explaining code workshop
  3. Morning break
  4. Discuss different continuation styles
  5. Games, rules, logic and strategy
  6. lunch
  7. demo
  8. Study Group
  9. Code Review
  10. Afternoon break
  11. Study Group
  12. Retro

✍🏽 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

🔗 Explaining code workshop

Learning Objectives

Explaining code

We often need to explain our code to others. Some examples of when we need to do this:

  1. When someone else is going to start working on it with us.
  2. When trying to get help with our code from someone else.
  3. In a job interview.

Pick a project you’ve been working on recently to explain. The project doesn’t need to be complete, but it should be at least 100 lines of code and should take more than a couple of sentences to explain.

The big picture (15 minutes)

Start by introducing the big picture of the code:

  • What is the project?
  • What problem does it solve?
  • How does the program generally work?

Do this before digging into specifics (e.g. what a function does, what some lines do).

5 minutes: On your own, think about how you will explain the big picture of a project. What is useful for someone to know? In what order is it useful to introduce those ideas? Once you have an idea, try thinking through how you would explain the project you’ve chosen.

Volunteers: Facilitate this discussion:

10 minutes: Discuss as a whole class your ideas for how to introduce the big picture of a project. At the end of this discussion, you should have a template of a script with the different topics you would explain.

Explaining specific code (15 minutes)

5 minutes: On your own, think: how would you like a new codebase to be explained to you? Some things to consider:

  • Where would you want the explainer to start?
  • Would you want to go depth first (keep following all of the function calls before you move into the next line) or breadth first (read each line of a function, before looking at the functions it calls)?
  • What kind of example data may be useful to consider?
  • Is it more interesting to focus on normal cases or unusual cases (e.g. errors)?

Volunteers: Facilitate this discussion:

10 minutes: Discuss as a whole class your ideas for how to walk through specific code. At the end of this discussion, you should have a template of a script with the different topics you would explain.

Walk through (50 minutes)

Split into pairs (and a group of three if needed).

Imagine you are in a job interview, explaining your project to an interviewer. The interviewer doesn’t know anything about your project.

Take turns to explain your chosen project codebase to your partner. Use the frameworks you established earlier in the workshop. At the end of your explanation, your partner should be able to talk about and explain the code you showed them. Feel free to ask/answer questions on the way.

Make sure that each partner has an equal time to explain their codebase.

Volunteers: Observe different groups explaining code. Feel free to ask questions or give feedback as you do.

Wrap up (10 minutes)

As a whole class, discuss your experience. What techniques did people use that helped make things clear? When were you confused? What could people have done differently?

How will you explain things differently next time?

🫖 Morning Break

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

🧰 Discussion: Continuation styles

Learning Objectives

In the prep you should have compared (at least) three different ways that ensureFields could be written.

In groups of about 4, discuss your thoughts on the advantages and disadvantages of each.

Do you all agree? If not, what do you think you value differently?

Try to come to a decision about which implementation you like best, and why.

🎲 Games, rules, logic, and strategy

We have some favourite games you can play if you are stuck.

  1. Traffic Jam: re-order the cars to unblock yourself
  2. Telephone: draw the words and write the pictures
  3. Set: a game of visual perception
  4. Mastermind: a game of deduction
  5. Sudoku: a game of logic
  6. Mancala: a game of strategy

🍽️ 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.

🎤 Demo

At CYF we expect you to demo your work to the class. You must have many opportunities to practice how to clearly and simply explain your work to others. This is really important both for interviews and for getting promoted later on.

⏰ Timekeeper

The timekeeper will keep the groups on track.

Split randomly into groups of no more than 5 people. Each person will have 2 minutes to demo their work to the group. After the demo, the group will give feedback for 5 minutes. Then the next person will demo their work.

🧑🏼‍🎓 Trainees

1. Demo

You will demo your work to the group. You will have 2 minutes to explain what you did and why. It’s ok to show broken code or code that doesn’t work yet. Just make sure your demo is interesting.

2. Feedback

After the demo, the group will give you feedback for up to 5 minutes. It’s smart to suggest what kind of feedback you want by asking some “generative” questions. For example:

  • I wasn’t sure if it makes sense to try X. What do you think?
  • I liked the way I did X, but I know there are other approaches, what did you do?
  • I found X really confusing, did anyone else have the same problem?
  • I wasn’t sure if I explained what an X was very clearly, how could I have explained it better?

💡 Tips:

  • Practice your demo before class.
  • Keep it simple. Don’t try to show everything you did. Just show one interesting thing.
  • Keep it short. Two minutes is enough.
  • Explain what you did and why.
  • Show your code.
  • Ask for feedback.

🛗 Study Group

Learning Objectives

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

🛎️ 0 PRs available. Open some 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

Learning Objectives

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

🔄 Retro: Start / Stop / Continue

🕹️Retro (20 minutes)

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.