Code Your Future - Home

🧑🏿‍🤝‍🧑🏾 day-plan

🔖
  1. Energiser
  2. Goal of this module
  3. Ground rules
  4. Reviewing and improving your goals
  5. Morning Break
  6. Gathering requirements
  7. Lunch
  8. User Interface
  9. Data
  10. Afternoon Break
  11. Project Work
  12. Prep for the week

Bad Interview Answers 🔗

Learning Objectives

Preparation

Grab a list of common interview questions from somewhere like Coursera.

Please set a timer for 15 minutes.

Introduction

We have a lot of serious work to do, but let’s start with some fun

Let's energise

🎯 Goal: Let’s wake up and have a laugh (15 minutes)

1. Interviewer: Cold call a random person and ask them an interview question. Choose an ordinary question.

2. Interviewee: You must give a terrible answer to this question (keep it clean, please!). Then cold call another person to be the interviewer.

3. Interviewer: Give absolutely straight-faced feedback. If you laugh, you’re out and must nominate another player to complete your feedback and return the game to step 1.

Goal of the Portfolio Module 🔗

Learning Objectives

Preparation

Must have done the prep work for this module

Prep for the exercise on the day:

  1. One person volunteers to ask the questions and choose who is answering them. You can ask each question several times.

  2. But choose a different person every time. We must hear different voices!

  3. Set a 15 minute timer and wrap up promptly.

Introduction

Let’s have a quick discussion about the Portfolio Module!

What are we doing in the Portfolio Module?

🎯 Goal: Align the knowledge of the group about what we are trying to achieve (15 minutes)

In one big group, let’s make sure we all understand the Portfolio Module’s goals.

Questions to be discussed:

  1. What are you doing in the Portfolio Module?
  2. Name one of the module success criteria, and why it is important?
  3. How long is the Portfolio Module?
  4. How can you help make the Portfolio Module a success?

📏 Ground rules

Learning Objectives

We’re going to start off by defining rules and expectations for working on projects during this module.

📐 Ground rules

  1. We go together
  2. Do one project at a time
  3. We will put in the time - 25 hours

🏗️ Projects

  • We start a new project when everyone has finished the current one
  • We can work as individuals or in groups
  • “Done” means “Good enough to show an employer”
  • 1 great user story is better than 10 meh user stories

🗣️ Communication

  • Post a link to your deployed application by midnight at the end of every Thursday
  • If everyone is ~done, we’ll start a new project on Saturday
  • If you’re not done, LIST YOUR QUESTIONS AND BLOCKERS
  • But don’t wait until Thursday to get help
  • We are flexible to people’s needs: but you must express your needs

Reviewing and improving goals 🔗

Learning Objectives

Preparation

Each trainee needs to bring and share their SMART goals and Weekly Activity spreadsheet.

Introduction

We will focus on your SMART goals and discuss them a bit further, getting feedback on them.

SMART quick-fire questions

🎯 Goal: Ensure the group has the same knowledge about SMART Goals (5 minutes)

Let’s quickly answer these questions.

  1. What does the S.M.A.R.T stand for? 
  2. Why do we use this acronym to help set goals? 
  3. Name some benefits of setting SMART goals over non-SMART goals.

Share your SMART goals in a smaller group

🎯 Goal: Receive feedback on your SMART goals and Weekly Activity spreadsheet (30 minutes)

Break the group up into small groups.

  1. Each trainee will present their SMART goals and Weekly Activity spreadsheet.
  2. The other team members will listen to it and then share their feedback, focusing on making the goals as SMART as possible.
  3. Each trainee should adjust their goals and Weekly Activity spreadsheet based on the feedback. (This can be done after class if you run out of time.)

Reflect on the previous exercise

🎯 Goal: Share the insights of the smaller groups (10 minutes)

Return to the main group and discuss any common themes or challenges that came up in the small groups.

Some questions that can help you guiding this discussions are below"

  1. Were most goals SMART, or did they need to be improved? 
  2. Did most of your goals align with your Weekly Activity plan?
  3. Does having SMART goals make you feel more confident in your chances of success?
  4. What were the common themes that came up as barriers to success?
  5. Do you share many of the same barriers?

How can we support each other?

🎯 Goal: Identify resources to support trainees to achieve their SMART goals (15 minutes)

Discuss as a group what solutions and support are available for trainees to overcome these challenges.

Questions to be asked:

  1. What resources were identified to help overcome these? 
  2. What can the community do to support you? 
  3. What can other trainees do to support you?
  4. What can you do to overcome these barriers?
  5. What should you do when you get blocked by one of these barriers?
  6. How can you help when these barriers block your peers?

Morning Break

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

🔎 Gathering requirements

Learning Objectives

Communication is hard. Today, let’s explore some ways we communicate with each other in software development. It’s not enough to draw a picture of a website and assume the other person will build what you imagine. It’s never a good idea to assume shared context or shared interpretations.

So how do we understand what to do? By understanding requirements.

Formalising Requirements

Today we’re going to think about requirements. We’re going to ask these questions:

  • why we’re working on a project
  • who we’re making it for
  • what they’re going to use it for.

Before starting to solve a problem (how), step back and ask yourself those why, who, and what questions.

We’re going to think about a few projects and discover some requirements. This is really important in order to do technical work, but you don’t need to have any coding experience, or be thinking about coding, when doing this.

Remember

To make great software, we need to think about people, not just code.

User Stories

We can discover requirements with something called ‘User Stories’. The simplest user story looks like this:

As a [type of user], I can [achieve some goal].

In addition to [who] and [what], good user stories also include [why]

As a [who], I can [what] so that [why]

Choosing a project

ℹ️ Use this section if you’ve not already chosen a project

Explore and discuss

🕥 Time: 30 minutes

📖 Read

Read the business problem carefully
Read ( if there are any ) the user stories carefully

❓ Questions

Answer the following questions:

  • Do you have any domain knowledge on this project?

  • Will you need to do more research to understand this business problem?

  • Does the business problem make sense? Can you explain the business problem in your own words?

  • Are there user stories for your chosen project brief? If not, sketch out some user stories.

  • If there are already user stories, check they make sense. Can you think of any more? Can you imagine the users of this application needing the stated functionality?

  • Does this project interest you?

Reflect and decide

Discuss

🕥 Time: 10 minutes

Get back together as a team.
Get one person from each pair to explain in their own words what the project brief is about.
Explain why you think you should do this project.

Decision

🕥 Time: 10 minutes

As a team, decide on which project you’re going to implement.

Community Lunch

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

🕹️ User Interface

Learning Objectives

As a team, you need to start thinking about and designing the user interface.
To focus your discussion, keep these two things in mind for your UI:

Sufficiency

Sufficient means enough for a given purpose. Your user interface should provide enough functionality or data for users to achieve their goals.

Simplicity

Simple means easy to understand. Think of the number of times you’ve used a website and it’s been impossible to find the things you need. Your user interface should be simple and intuitive. Users should be able to figure how to navigate and use the user interface with minimal effort.

discussion

🕰️ Time: 20 minutes

Split into pairs.
Each pair, choose a different user story.
Work on the following tasks, remember to focus on sufficiency and simplicity.

  1. What kind of pages will you need?
  2. What are the key components of this page (inputs, forms, buttons, cards, etc)
  3. Ensure you can clearly define the purpose of each page and its components
  4. What kind of data will you need to expose in this view?

🖼️ Wireframe

discussion

🕰️ Time: 20 minutes

Create some wireframes for the pages you described in the previous section
If you’ve not made wireframes before, check out this guide to help you come up with some ideas: https://balsamiq.com/learn/articles/what-are-wireframes/

🪞 Reflect and check

discussion

🕰️ Time: 10 minutes

Now swap wireframes between each pair.
Check the following:
Does the proposed interface meet the requirements for the user story?
Is it sufficient?
Is it simple?

🗃️ Data

Learning Objectives

For your application to work, your user interface will interact with other services. These services provide data and ways to update this data via the user interface.

Here are the kinds of things these services may do:

📖 Reading

A means of reading data. The user interface might fetch data from some external source and render it in the interface.

💾 Persisting

A means of persisting changes. Users will need to create or update existing data. For example, a user might need to create a comment on an article. Another user may need to update the like/dislike on an existing comment. In each of these cases, any changes are persisted in a database. The user interface enables users to read and persist data without worrying about the

Discuss

  • What are the key components of the application, how are they connected, is it a static or a dynamic application, what kind of data are you storing?

  • What sort of data does the client application need - what kind of data is it fetching?

  • What is the purpose of each component in your application, how will it communicate with other components in the architecture?

  • How do your different pieces of data relate to each other? If you’re storing things in a database, what tables will you need, and what relationships will there between the tables?

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.

🧩 Break it down

Learning Objectives

You’ll need to break up your user stories into manageable units of work.
Breaking down tasks into sub-problems is challenging: we often don’t know in advance how challenging the sub-problem will be. However through iteration, practice and feedback we can continue improving how we break problems down.

🎟️ Issues

You can keep track of work using a GitHub project board as you’ve done throughout the course.

Write your issue

⏰ Time 20 mins

  1. On your GitHub project board
  2. Create a new issue
  3. Set the title to the user story you just chose

✅ Acceptance criteria

If you’re working on something, then you need a definition of “done”. In other words, you need to have measurable criteria for knowing when you’ve completed some task. Acceptance criteria are the requirements that must be met for a unit of work to be considered complete. Most often you’ll ue acceptance criteria to decide whether a user story has been implemented. Here are two ways of expressing acceptance criteria:

  • Scenario-oriented (the Given/When/Then template)
  • Rule-oriented (the checklist template) and

🫱 More detailed information on writing up acceptance criteria.

Note

⏰ Time 20 mins

  1. Choose one user story
  2. In pairs, come up with acceptance criteria. Decide on scenario-oriented or rule-oriented acceptance criteria.

Prep the work for the week 🔗

Learning Objectives

Introduction

Good teams communicate well. Get clarity on who will be doing what and when.

Planning the next steps

🎯 Goal: Have a clear plan for the team (10 minutes)

Considering all the work done today, what are the next steps you must take as a team?

Some prompt questions that might help if you haven’t discussed them yet:

  • Who will raise which tickets?
  • Who will set up the meetings?
  • Who will work on which tickets and how will we know?
  • What time is the best for pair programming?
  • What questions do you have?
  • Are you confident about what you must do from tomorrow?