Day Plan

πŸ”–
  1. Morning orientation
  2. How we work
  3. Goals
  4. Using a project board workshop
  5. Morning break
  6. Terminal skills workshop
  7. Lunch
  8. Demo
  9. Study Group
  10. 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

How We Work

Learning Objectives

SDC works just like ITP:

  • Each sprint starts on Tuesday.
  • You are expected to read all of the prep before coming to class.
  • You are expected to look at and start trying all of the backlog items before coming to class.
  • Class runs on Saturday
    • In the mornings we do group workshops.
    • There’s a lot of time for study group - get help with what you need help with!
    • Every sprint there is time for demos. Practicing giving demos is incredibly important. Work out with your cohort how you want to run these: Should everyone demo every week, or will you take turns? How long should each demo be? What kind of feedback do you want?
  • You should finish all of your backlog items, and get your work reviewed. Keep iterating until it’s complete.

It’s also a bit different from ITP:

  • It’s much less guided. There’s a lot more unstructured time for you to decide what you want to focus on or need help with.
  • There are only a few (big) backlog items, rather than lots of small ones. You should break these down and plan them yourself.
  • There’s less checking and hand-holding. We trust you to do your backlog and get it reviewed. You don’t need to submit a step proving you’ve done so. But you still need to do the work. If you haven’t finished all the work from two sprints ago, something is wrong, talk about it.
  • At the end of each sprint there is a retro. Use this time to discuss what isn’t working well, and what you want to change about how your cohort is doing the course.

Discussion

Discuss as a cohort how you will work together.

How do you want to collaborate?

How do you want to do demos?

How do you want to structure Study Group time?

What will you do if you fall behind? How will you get support?

Goals

Learning Objectives

The goal of the Software Development Course is for you to learn transferable fundamental skills in software. This will prepare you for many different jobs. You will not be limited to one job style, like “web developer” or “backend engineer”. You should be able to apply for any job that involves writing software.

The course uses JavaScript and Python, but gives you foundations to learn any language you need. You can apply for jobs in languages you don’t know. (But make sure you know what they expect you to use in an interview!)

Discussion (10 minutes)

Discuss in your cohort what kind of sector you each want to work in (e.g. Finance, Cloud Infrastructure, Education, Green Energy, Mobile Games, …). Find out what your volunteers do (and have done).

Discussion (20 minutes)

Discuss in your cohort what jobs you’ve heard of in the software industry. Find out what your volunteers do (and have done).

What do you know about them? What do you like about them? What do you want to work as?

Make sure you cover at least the following, but bring any you know too:

  • Software Engineer
  • Infrastructure Engineer
  • Backend Developer
  • Frontend Developer
  • Sales Engineer
  • Forward-deployed Engineer
  • Consultant Engineer
  • Full-stack Developer
  • Platform Engineer
  • Site Reliability Engineer
  • Automated Tester
  • Manual Tester
  • DevOps Engineer
  • Cloud Engineer
  • Java Developer
  • React Developer

πŸ”— Using a project board workshop

Using (and getting value from) a project boards

Project boards are a key tool used by teams to manage their work. Let’s find out together why.

Discussion (15 min)

Make a circle with the trainees (if you have more than 20 people in class, split it into 2 groups)

Each trainee should answer the following question:

  • What problems are we trying to solve with project boards and tickets?
  • Have you heard of reading from the right to the left? And can you explain it to the group?
  • Can you explain the concepts for work in progress?
  • What are work in progress (WIP) limits and how are they useful? How should we set them?

PS: If no one knows the answers, Google it and discuss it

Exercise (25 min)

Separate teams in groups of 4.

3 people should take on the role of “developer” and one person the role of “QA”.

Make a copy of this Miro board. The board tracks is for a project which tracks to progress of trainees.

Look at the board and discuss:

  • What is each column for? Why is each column useful?
  • What WIP (work in progress) limits may we want to apply to each column?
  • Which ticket would you pick up first and why?
  • What information could help us decide when we’re not sure?
  • How should we prioritise tickets in each column?
  • How can we be effective at moving tickets to done?
  • Is there anything we could remove from the board?
  • How can you ask for help from your team or give help to your peer?
  • How can I tell my team just with this board where I am at with my ticket?
  • We discussed a teamwork board. Can any of the things we learned today be applied to your individual coursework board?

Wrap up (5 min)

Make a circle with the trainees.

Each trainee should share one thing they learned today.

Morning Break

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

πŸ”— Terminal skills workshop

Terminal skills

Developers frequently use the terminal to interact with their computer. It is a useful job skill to get comfortable doing this.

In this workshop you will experiment with a terminal while there are volunteers around who can help you.

Split into groups, one volunteer per group. Volunteers, please follow along on your own machine, and be ready to offer help, ask helpful questions, and unblock. (But please also keep your hands off the keyboards of your group. )

Why do we use the terminal?

Collect reasons (2 minutes)

Set a timer for 2 minutes. Write down as many reasons people use the terminal as you can.

Share reasons (3 minutes)

Popcorn around the group sharing reasons for using the terminal.

Consider an example (2 minutes)

One reason developers use a terminal is to query files, or find out information. There are lots of existing tools that search, sort and change data.

Developers often write tools that other people can use in scripts or pipelines.

For instance, git exposes a lot of information that you can conveniently consume in a script.

We can find the names of people (or bots) who have contributed to a Git repo by running:

git log | grep '^Author:' | awk -F'[<>]' '{print $2}' | grep -v 'users\.noreply\.github\.com' | sort | uniq

Or sort contributors to a Git repo by number of contributions:

git log | grep '^Author:' | sed -e 's/^Author: //' -e 's/ <.*$//' | sort | uniq -c | sort -r -n

curriculum % git log | grep '^Author:' | sed -e 's/^Author: //' -e 's/ <.*$//' | sort | uniq -c | sort -r -n
 790 Sally McGrath
 787 Dedekind561
 231 MitchLloyd
 176 Daniel Wagner-Hall
 151 KFK
  70 Alasdair Smith
  38 Lara Huzjan
  14 Barath Vignarajah
  11 Caroline (Frank) Scherf
  10 Barny Dathan
   8 omahs
   7 Zsolt Sz. SztupΓ‘k
   6 dependabot[bot]
   5 Sam Pennington
   4 Metin Barış
   4 Anna Aitchison
   3 karen
   3 Amy
   2 daslerr
   2 Rabia Avci
   2 Kyrylo Kovzel
   2 Jonathan Zheng
   2 Jay Mayer
   1 metinbaris
   1 karam ali
   1 Vlad Boisa
   1 Varuna
   1 Tony Beaumont
   1 Mohamad Badrawy
   1 Isar
   1 H. Nhi (Alex)
   1 FridIsar
   1 Fikret Ellek
   1 Della Bella
   1 David Christensen
   1 Chris
   1 CJ Yuan
   1 Berkeli Halmyradov
   1 Baz
   1 Azar Alampanah

These would be hard questions to answer without some kind of program or script. By combining re-usable tools, we can quickly answer them. (You’ll learn more about combining tools next sprint!)

Being effective with the terminal

This is a list of exercises for you to try on your own. You will probably get stuck or confused. Ask the people around you (either volunteers or trainees) when you’re stuck.

Volunteers: Make sure people aren’t stuck, and help them when they are.

Shell scripts

Sometimes we want to re-use some series of commands, or share them with other people. To find our top Git contributors it’d be nicer to run get-top-git-contributors. That would be clearer and simpler than remembering and running all those commands each time.

A way of doing this is to write them in a script. A terminal is also called a shell, so these are called shell scripts.

The format of a shell script is to put one command per line. Often the very first line will be #!/bin/bash, to tell the computer what program should interpret the script.

There are three ways you can run a shell script:

  1. As an argument to bash. If you run bash /path/to/your/get-top-git-contributors, your script will be run.
  2. By making the script executable. You do this by running chmod a+x /path/to/your/get-top-git-contributors once. After this, you can run your script by putting its path into your terminal. This means running /path/to/your/get-top-git-contributors, or ./get-top-git-contributors if you’re in the same directory as the script.
  3. By making the script executable and putting it on your $PATH. Once you have done this, you can run it by name: get-top-git-contributors.

Make some shell scripts (20 minutes)

Make a shell script (it can do whatever you want - print something, look up git information, or something else completely!). Run it via all three of the ways described above. Run it from a few different working directories.

If you aren’t sure what shell script to write, try to write a script which does all of the following:

  • Outputs the current date and time (using the date command).
  • Outputs the current working directory (using the pwd command).
  • Outputs the current user’s username (using the whoami command).
  • Outputs a friendly message to the user, e.g. saying “I hope you have a good day” (using the echo command).

Running previous commands

Often we want to run a command we ran in the past. Shells support this. Pressing the up arrow will bring the last command you ran. Keeping pressing it will cycle through.

Pressing Control+r and typing some text (like git) will search back for the last time you ran a command containing that text. Pressing Control+r again will go back to the command before that contained that text.

Practice running previous commands (5 minutes)

Run the following commands in a row:

% git status
% echo "Hello"
% git rev-parse HEAD
% echo "I ran a command"
% echo "I ran another command"
% date

Find the last git command you ran with Control+r. Change the argument HEAD to the argument main and run it.

Practice using the up arrow, and Control+r to search for, edit, and run other previously run commands.

Often we have typed a command we’re going to run, but we need to slightly change the command. Maybe we made a typo, or need to change an argument.

Many terminals don’t let us just click around to change the position of the cursor. We can use the left and right arrows to move around one character at a time.

Shells also support moving the cursor one word at a time, or jumping all the way to the start or end of your line. Work out how to do this, practice it, and take notes to help you remember how.

(Note: This may be different on different operating systems!)

Avoiding needing to type everything (5 minutes)

Shells support tab completion (pressing the tab key to fill in the names of files), and expansion (using special characters like *) to avoid you needing to type in the full names of files.

Use both of these techniques to run commands involving files without needing to type out all of their full names.

Wrap up

Run through the learning objectives of this workshop. Make sure you have achieved them. If you’re not sure about any of them, work on them in study group or in the week.

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

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-team Slack channel canvas.

Breaks

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

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.