🧑🏽‍🤝‍🧑🏽 day-plan

🔖
  1. Morning Orientation
  2. Job Descriptions and Questions
  3. Morning break
  4. Writing bug reports
  5. Lunch
  6. Study Group
  7. Code Review
  8. Afternoon break
  9. Study Group 2
  10. Retro

✍🏽 Register

🎡 Morning orientation

Learning Objectives

info

🧭 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 MCB {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

Job Descriptions and Questions for Employers

Learning Objectives

Preparation

You must have done the prep work.

Introduction

To find a good job, you must know how to ‘play the game’. This includes understanding how to interpret Job Descriptions and assess which are going to be a good fit for you, and which to avoid wasting your time on.

Review each others’ Job Description analyses

🎯 Goal: Help each other interpret Job Descriptions and assess whether they are worth pursuing. (40 minutes)

Form into groups of 3 and take turns reviewing each others’ Job Description analyses from the prep. Spend about 10 minutes per person.

Questions to consider:

  • Do you agree with their assessment of which requirements were met?
  • Do you spot any additional red flag warning phrases or keywords?
  • Are there additional questions you would ask to get clarification from the employer?
  • Do you agree with their assessment of whether to apply or not?

Questions for employers

🎯 Goal: Clarify your understanding of a Job Description with a potential employer (20 minutes)

In the same groups you worked on before, discuss questions for employers.

You don’t want to waste your time or the employer’s time applying for jobs that are not a good fit. So it can be a good idea to ask the recruiter or employer questions about the job you are considering before applying. Some job descriptions are unclear or vague, and you may be uncertain about the core requirements. Also, since this is probably your first contact with the employer, it shows genuine interest in the role and asking good questions early on makes you stand out versus your competition for the job.

As a group, list good questions to ask the employer or recruiter before applying for the position. What questions should you not ask?

Hint: you want a solid understanding of the role, what the key challenges are, why it is being offered, and what’s expected from you on a typical day, but you want to phrase the questions to make it clear you already know the Job Description thoroughly.

Morning Break

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

Writing bug reports 🔗

Asking Questions 101

Prep

  • Read this article about Mental Models
  • Review the Asking Questions workshop and the CYF Guide to Asking Questions on the curriculum.

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

  1. What I did
  2. What I expected
  3. What actually happened

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

It’s also an efficient way to share our current understanding with others. Now we’re going to use this to write a really good bug report. A well-written bug report can help developers identify, reproduce, and fix issues more efficiently. We will follow this basic format:

  1. Steps to Reproduce (What I did)
  2. Expected Behavior (What I expected)
  3. Actual Behavior (What actually happened)
  4. Environment Details 🆕

Clarity is our goal

Exchanging incomplete information sets 30m

ContextOver and over, especially during The Launch, we see trainees writing panicked, incoherent questions with no context, pasting error messages they clearly have not read, and not even sharing the link to the code they're working on.

Outside our community, developers will ignore or delete your posts if you do this. At home with us, well-meaning mentors often try to help you, but they can’t because you haven’t given them the information they need. It feels so frustrating, and people can get really upset. We want to help you avoid this as you prepare to work in a professional environment. Your colleagues will enjoy answering your questions if you give them the information they need; most developers really like solving well-constructed puzzles.

😎 Useful questions -> colleagues enjoy answering -> get solutions promptly -> make lots of progress -> good performance
😰 Not useful questions -> colleagues avoid answering -> don’t get solutions -> take much longer -> performance appears poor

Steps to Reproduce

When you’re writing a bug report, you need to be able to reproduce the bug. This means you need to be able to make it happen again. The person reading the report needs to be able to follow your steps and cause the same error.

Here’s an example of steps to reproduce:

  1. Go to my deployed site at https://my-site.com
  2. Click the “Login” button top right
  3. Choose “Sign in with GitHub”
  4. Authorise with GitHub and be redirected back to the site
  5. Login page error says To confirm your identity, sign in with the same account you used originally.

Bad bug reports

activity

  1. Set a timer for 5 minutes.
  2. Popcorn around the room and each person give an example of a bad way to ask a question until the timer goes off. For example:

“I was on the site, and then I clicked something, and it didn’t work!”

Why are these not useful?

activity

  1. Set a timer for 10 minutes.
  2. Popcorn around the room and each person give a reason the previous question was bad until the timer goes off. For example:

“What site are you on? What are you trying to do? How can I read your post and re-create the circumstances. Be specific! Share what you see.”

Expected behavior

What you expected to happen

When you’re writing a bug report, you need to be able to explain what you expected to happen after you executed the steps you just described. You might feel this is so obvious that you don’t need to write it down, but this assumption is drastically, drastically wrong.

Here’s an example of expected behavior:

“I expected to be able to log in with my GitHub account and be redirected to the logged-in view of my dashboard on my site.”

Actual behavior

What actually happened

Here’s an example of actual behavior:

“Instead, I was redirected back to the login page with an error message that says To confirm your identity, sign in with the same account you used originally.”

activity

Look at the difference between the two examples above. What do you notice? Apart from the user’s reported problem, what is the difference between the actual behaviour and the expected behaviour? It’s subtle.

  1. Set a timer for 3 minutes.
  2. Popcorn around the room until you spot the difference.

Error messages

What the computer told you

Have you ever considered, and this is just a wild idea, reading the error messages that your computer gives when it goes wrong?

Just kidding! We know all trainees are implacably opposed to reading error messages. But here’s the thing:

  1. When you’re writing a bug report, you need to include the error messages you’re seeing. This is crucial information for anyone trying to help you.
  2. You also need to read the message yourself first. If you cannot understand it, you need to say what you don’t understand about it. This is the gap in your understanding that you need help with.
Here's a common exchange we see:

Trainee

I am unable to run my code. Every time it’s saying this; npm ERR!

Missing script: "dev"
npm ERR!
npm ERR! To see a list of scripts, run:
npm ERR!   npm run
npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/student/.npm/_logs/2024-02-26T19_28_05_701Z-debug-0.log

Mentor

What happened when you followed the suggestion in the error message?

Trainee

…What suggestion?

activity

  1. Set a timer for 3 minutes.
  2. Popcorn around the room and find the instruction in the error message.
>

Error messages aren’t always correct, but they are a valuable clue.

  1. Read the error message
  2. Identify suggestions
  3. Find out what they would do (this also means being able to form a hypothesis to test)
  4. Then (maybe) do them.

Environment Details

The conditions in which the bug occurred

When you’re writing a bug report, you need to be able to describe the system you were using when you encountered the bug. Because all these details matter!

Here’s an example of environment details:

VSCode on Windows 10, Node v14.15.4, NPM v6.14.10, React v17.0.1, deployed to Netlify.

Let’s improve a bug report together to understand why details like this matter.

Iterative improvement of a bug report 15m

🐛 Bug Report Fail

Bug: I can’t create any files in my project
I’m trying to create files in my repo but it just errors. I don’t know what’s wrong. Please help me!

This is a terrible bug report. Popcorn around the room and name four problems with it.

🐛 Bug Report Improvement 1

Bug: cannot create new files on the command line

Steps to reproduce:

  1. Open repo in VSCode
  2. Try creating a new file in the terminal
  3. Get error that says I can’t create the file.

Expected behaviour

I expected to create a new file in the terminal

Actual behaviour

Instead, I got an error message

OK now we have some more information given. We’ve got some steps to reproduce and some expected and actual behaviour. But it’s still not great.

activity

  1. Set a timer for 5 minutes.
  2. Popcorn around the room and name three problems with this bug report. How should it be improved?

Send it back!

🐛 Bug Report Improvement 2

Bug: cannot create a new file on the command line

Steps to reproduce:

  1. Open repo in VSCode
  2. Open terminal and type touch newfile.js
  3. Get error 'touch' is not recognized as an internal or external command, operable program or batch file.

Expected behaviour

  • I expected to create a new file in the terminal using the touch command.

Actual behaviour

  • Instead, I got an error message 'touch' is not recognized as an internal or external command, operable program or batch file.

activity

Our bug reporter has worked hard on improving their bug report. But there is one crucial detail missing.

  1. Set a timer for 5 minutes.
  2. Popcorn around the room and guess/suggest how this bug report could be improved with one more detail.

🐛 Bug Report Final Form

See how much easier is to fix in the final form? What is the bug in this report?

Bug: cannot create a new js file on the command line

Steps to reproduce:

  1. Open repo in VSCode
  2. Open terminal and type touch newfile.js
  3. Get error 'touch' is not recognized as an internal or external command, operable program or batch file.

Expected behaviour

  • I expected to create a new file in the terminal using the touch command.

Actual behaviour

  • Instead, I got an error message 'touch' is not recognized as an internal or external command, operable program or batch file.

Environment details:

VSCode on Windows 10, Node v14.15.4, NPM v6.14.10, React v17.0.1, deployed to Netlify.

Wrapping up

Recapping the key points:

Include as much context as you can, including links, line numbers, sample code, etc. Use code blocks to mark up your code. If you use screenshots, they should only show the visual render (never screenshot code - paste code as text).

🧑🏾‍💻🙋 Bug reports contain

  1. 🔗 Links 👍
  2. 🎯 Objectives - what are you actually trying to do? 👍
  3. 🖼️ Screenshots of UI if relevant 👍
  4. 📝 Code blocks 👍
    • In Slack, proper code snippets get syntax highlighting and can be collapsed vertically - remember to 🧵 use threads too
  5. 🪸 Environment details 👍
  6. 📷 Screenshots of code 🙅

📚 Further reading

Bug fixing friends

Lunch

Take your lunch break and be back in an hour!

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

🛎️ Code waiting for review 🔗

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

NW6 | Fathi Kahin | Module-Database | E-commerce -API-| Week 4 🔗

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
WM5 | AISHA_ATHMAN_LALI | MODULE_DATABASES | WEEK_3 | CYF_E-COMMERCE 🔗

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

This is a PR on CYF E-COMMERCE.

Questions

Are there better ways I could have written the queries?

Start a review
WM5 | AISHA_ATHMAN_LALI| MODULE_DATABASES | WEEK_2 | BIG-SPENDER 🔗

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

This is a PR for the big-spender database project.

Questions

Is there a better way I could have written the queries?

Start a review
NW6 | Pedro Ricciardi | Databases Module | [TECH ED] E-Commerce API | Sprint 4 🔗

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 meet the requirements of this task

Changelist

All routes and tests implemented following the user stories in readme.md:

  • As a user, I want to view a list of all products with their prices and supplier names.
  • As a user, I want to search for products by name.
  • As a user, I want to view a single customer by their ID.
  • As a user, I want to create a new customer with their name, address, city, and country.
  • As a user, I want to create a new product.
  • As a user, I want to create a new product availability with a price and supplier ID, and get an error if the price is not a positive integer or if either the product or supplier ID does not exist.
  • As a user, I want to create a new order for a customer with an order date and reference number, and get an error if the customer ID is invalid.
  • As a user, I want to update an existing customer’s information with their name, address, city, and country.
  • As a user, I want to delete an existing order and all associated order items.
  • As a user, I want to delete an existing customer only if they do not have any orders.
  • As a user, I want to view all orders with their items for a specific customer, including order references, dates, product names, unit prices, suppliers, and quantities.

Issue

[TECH ED] E-Commerce API

Note

Due to a lack of time, I could not create my own acceptance criteria. I focused on the most important aspect, which is the correct implementation and testing for each route.

Start a review
NW6 | Rabia Avci | Databases Module | [TECH ED] E-Commerce | 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

I have written SQL queries to retrieve specific data from a database with different tables with relations between them.

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

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

  activity</span>

A retro is a chance to reflect. You can do this on a FigJam (make sure someone makes a copy of the template before you start) or on sticky notes on a wall.

  1. Set a timer for 5 minutes. There’s one on the FigJam 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.