Every session begins with an energiser. Usually there’s a rota showing who will lead the energiser. 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. 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.

👣 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.

Professional Q&A Experience Workshop

In ITP you have practised giving demos - short presentations to get practice speaking in a professional setting. Later on, during an interview, presentation, or other work discussion, you will also be expected to ask and answer questions. The goal of this workshop is to give you practice in asking meaningful questions and giving good answers.

Plan

To get the best out of this workshop, please use a short demo on a topic you are comfortable discussing. The goal here is not the quality of the demo. It is to practice questions and answers, so you can re-use a demo you have previously given.

There are 2 criteria we want to meet:

• Every listener should ask at least 1 question during this workshop
• Every presenter should answer at least 1 question during this workshop

Take a moment to read through the tips below before you begin. Feel free to refer to these tips during the Q&A if that would help.

To ensure everyone has a chance to take part, get into groups of at most 5 trainees (and ideally at least one volunteer).

Take turns:

• Each demo should be no more than 5 minutes long
• Give up to 3 minutes for questions and answers
• Try to keep questions short, take up to 1 minute to answer

After everyone has had a chance to practice asking and answering, have a discussion as a group about the process:

• How did you find asking and answering: Was there anything easy or difficult about it?
• Give each other feedback on their Q&As: Did any good examples stand out, could any have been improved?
• What would you do differently if you were in a similar Q&A situation in the future? The feedback and discussion for this workshop should focus on the questions and answers, not the content of the demos.

Tips for Asking Good Questions

• This is different to the kind of rhetorical question you might have used when doing a demo
• Unless the speaker made it clear they want you to, don’t interrupt them mid-demo
• If the speaker says something you would like to know more about, you can remember it and ask at the end
• If the speaker said something unclear, or that you disagree with, you can ask politely about it at the end
• A good question is short and to the point. Remember: as the audience you’re not the main focus

Example Questions

The best questions to ask come from ideas the demo made you curious about. If you can’t think of any, you can use or adapt one of these, if they’re appropriate:

• If you were to do it again, what would you do differently?
• What did you enjoy the most about this?
• What was your biggest challenge?
• How does this compare to (some other way of doing something similar)?
• Could you explain how (this idea) could be used or adapted for (some related setting or project)?
• When I tried something similar, I encountered (this problem), how did you overcome that?

Tips for Giving Good Answers

• Know that you will never be able to prepare for every possible question.
• Listen carefully to what is being asked - you don’t want to answer the wrong thing.
• If you did not understand the question, you can ask them to reword it.
• Take a moment to think about your answer before you start to speak.
• Repeating the question back in your own words gives you time to start forming an answer, and it confirms to the asker that you understood what they were asking.
• If you can’t think of a good answer, it is fine to say you don’t know. This is better than giving an unclear long-winded reply.

Extra resources

• Asking questions at work
• Asking follow-up questions
• Using active listening
• Answering audience questions

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

When a team builds a project together, we break the big job into smaller tasks. But breaking work into small tasks is only half of it. We also have to agree how those tasks fit together, so people can work on them at the same time without blocking each other.

Today we will look at how this worked on a project you have already done, learn the steps to do it on purpose, and then practise on a new one.

Part 1: How Tic-Tac-Toe let you work in parallel

In the terminal Tic-Tac-Toe project, three people worked at the same time, each on a different file:

• board-printer.js
• move-maker.js
• status-checker.js

and play.js tied everything together.

Why were you able to work on these at the same time, without waiting for each other? Because two things were agreed before anyone started writing code.

1. The shape of the data. The board is always a 3 by 3 array of arrays, holding 'X', 'O' or '_':

const board = [
  ["X", "_", "_"],
  ["_", "X", "_"],
  ["O", "O", "X"],
];

Every function in every file expects the board to look exactly like this.

2. The function signatures🧶🧶 function signaturesA function’s signature is its name, the parameters it takes, and what it returns. If two people agree a signature, they can each rely on it without seeing the other’s code. . What each function is called, what it takes, and what it returns:

• printBoard(board)
• makeMove(board, move, player) returns true or false
• isGameOver(board) returns true or false

Once these are agreed, the person writing printBoard doesn’t need to wait for the person writing makeMove. They both already know what a board looks like and what their own function must do.

This is the whole trick: agreeing the shape of the data and the interfaces up front is what lets a team work in parallel.

Part 2: How to break a project down for parallel work

Tic-Tac-Toe was already broken down for you. Now let’s make the steps explicit, so you can do it yourselves. Whenever a team takes on a project:

1. Understand the requirement. Be clear on what the finished thing must do.
2. Agree the shared data and interfaces first. Decide the shape of the data everyone will pass around (like the board), and the signatures of the functions that connect the pieces. This is the most important step: it is what lets people work without waiting for each other.
3. Split the work into tasks. Give each person a piece they own: a file, a function, or a component.
4. Find the dependencies and order them. Some tasks need something from another task. Arrange them so nobody is stuck waiting.

Dependencies don’t have to block you

Even with a good breakdown, some tasks depend on others. In Tic-Tac-Toe, status-checker.js uses a function called checkIfNoMovesLeft, which lives in board-printer.js. That is a dependency: one task needs something from another.

But notice you were not blocked by it. Because the name and behaviour of checkIfNoMovesLeft(board) were agreed, the person writing status-checker.js could rely on it before it was even finished. Agreeing the interface breaks the block.

How do you carry on before the real function exists? You stub it: write a placeholder that matches the agreed signature and returns a fixed sample value, so your code can be built and tested before the real version is written. The Tic-Tac-Toe files started exactly like this: empty functions with agreed signatures. In the simplest case you can even hardcode a value (write a fixed value straight into your code) to work against, and swap in the real thing later.

Part 3: Break one down yourselves

Now practise the four steps on a new requirement.

Requirement. Your group is building a small app that shows a to-do list on the page. It must:

• let a user add a to-do,
• show all the current to-dos.

The to-dos are held in a global variable while the app is running, so it is fine if the list resets when the page is reloaded.

Takeaway

Before splitting work across a team, agree the shared data shapes and the interfaces between the pieces. Then everyone can work in parallel, and dependencies stop being blockers.

Every Saturday, we 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 let’s work together. These are the roles we need help with.

• Food shopping: ensure enough food is available for all courses running in your region, respecting the dietary requirements and the budget (you might not be the one buying the food, but you should ensure whoever buys or cooks the food knows what should be bought)
• Setting up the table: organise the food so that everyone has access to it and invite people to join lunch
• Washing up & tidying: your location should be as clean as it was before you all arrived in the morning. This can include washing up, taking the litter outside, hoovering, etc.

You can do something different every week or every two weeks. You shouldn’t have to be constantly responsible for the same task. Agree as a cohort on how you will manage this.

Questions you can use to help this organisation:

1. How long should each person (group of people) be responsible for each goal? 1 week? 2 weeks?
2. How will we communicate to our community who is the person responsible right now?
3. Is there any role missing?

Trainees

This is time for you to get help with whatever you need help with.

If you didn’t understand something in the prep, ask about it.

If you were struggling with a backlog exercise, get help with it.

If you weren’t quite sure of something in a workshop, discuss it.

If you don’t have any problems, keep working through the backlog until you need help.

It can be useful to get into groups with others facing the same problem, or working on the same backlog item.

Volunteers

Don’t be scared to approach people and ask what they’re working on - see if you can help them out, or stretch their understanding.

If lots of people have the same problems, maybe you can put together a demonstration or a workshop to help them understand.

If absolutely no one needs help, consider reviewing some PRs using the process and guidelines in the #cyf-code-review-volunteer-team Slack channel canvas.

Breaks

No one can work solidly forever! Make sure to take breaks when you need.

Finished everything?

If you have finished everything in the backlog you can use this time to practice some other skills which will be useful in your future careers. We have some suggestions below: