Our rules help create a friendly environment that is conducive to learning. We want everyone to feel comfortable sharing ideas and occasionally being wrong.

These rules are important, but they aren't severe like code-of-conduct violations. It's likely everyone will slip up and break a rule at some point: you aren't a bad person if you do.

We'd like everyone to feel comfortable gently correcting others' behaviour when they see rule violations. If you feel comfortable please point this out to someone—it's generally better to confront small problems immediately rather than letting them snowball into something bigger.

For example:

Oli: hey guys, how are you all doing?

Yvonne: good thanks! FYI would you mind not using gendered terms to refer to the group? Thanks!

Oli: Sorry my mistake!

If you aren't comfortable pointing out a rule violation then please message your course facilitator or other member of the core team. They can highlight the problem to the cohort.

For example:

Oli: hey guys, how are you all doing?

Yvonne (to course facilitator): hey would you mind reminding Oli not to call everyone "guys"?

CF (to everyone): hey Oli, just a reminder to try not to use gendered terms for the group!

Oli: Oh whoops, I'm sorry everyone!

If someone does point out that you broke a rule, try not to take it personally. One-off mistakes happen—it doesn't mean you're a bad person. Just apologise, reflect on your mistake and avoid doing it again.

Respect each other

Please be respectful of your peers on the course, the core team, and the wider community

Respect each others' time—make sure you arrive on time for everything on the schedule. This means being ready before the scheduled start time, not off making coffee. Also please let your course facilitator and cohort know if you're going to be absent.

Please demonstrate that you're paying attention to your peers, core team, speakers etc. E.g. don't lie down on your bed during a talk.

Respect each others' privacy. This is especially important when working remotely, since you're inviting each other into your homes via video calls. Please do not take screenshots or recordings of video calls without permission from everyone involved.

Avoid microaggressions

Microaggressions are subtle and unintentional acts of discrimination. They're insensitive comments that make somebody feel "other" for being a part of a group that is stereotyped or discriminated against.

There are plenty of subtle expressions of racism, sexism, ageism, homophobia, transphobia and other kinds of bias and prejudice. For example: referring to a mixed-gender group as "guys", or a white person asking to touch a Black person's hair.

This rule comes with a duty for everyone to educate themselves on social issues. Founders and Coders is not a normal coding bootcamp—one of our primary goals is to make the tech industry more inclusive. We can only do this if our graduates are willing to put in the effort to make change and be a better ally.

This rule is not about overt slurs, harassment or other Code of Conduct violations. Those should be reported to the core team and will be treated differently.

Avoid unnecessary corrections

Try not to correct someone unless the error is actually meaningful. Software engineers tend to care about being very specific and correct. This is a good trait when writing code, but makes for awkward conversation. An unnecessary interruption can throw off the person speaking and make them uncomfortable sharing further.

Oli: so you pass the parameter to this function...

Yvonne: actually parameters are when you define the function, they're called "arguments" when you call it

This is technically correct, but nobody was really confused by the initial statement, so it was not necessary.

Don't pretend to be surprised

Don't act surprised when someone doesn't know something. This will make that person feel bad for not knowing, and less likely to ask questions in the future.

Yvonne: what does querySelector do?

Oli: wow you've never used querySelector?!

The employment curriculum

In pairs from previous project teams

• Week 4 GitHub

• Week 5 Twitter

• Week 6 LinkedIn

• Week 7 Employment mentor planning

• Reading week Employment mentor intro

• Week 9 Portfolio site

In React pairs

• Week 10 CV & cover letter

With TfB team

• Week 11 Job boards & recruiters (talent.io, Hired)

• Week 12 Developing a strategy

  • Georgia's spreadsheet

• Week 13 Tools (Pramp, Leetcode) everyone to arrange Pramp session

With student project team - led by them and/or guest mentors

• Week 14 Applications

• Week 15 Tech tests

• Week 16 Interview prep

With week 1 team

• Week 17 Extracurricular skills

• Week 18 Data structures

One of the most important programming skills to develop is how to figure out what went wrong with your code.

It can be frustrating to write a bunch of code and immediately get a big error, so here's some advice to bear in mind.

You're not a bad developer

The most important thing is to remember that getting stuck doesn't say anything about you or your skill as a developer.

It's easy for your first reaction to be "I suck at this, no one else has these problems". Everyone makes typos, forgets how things work or gets inscrutable errors in their terminal. The mark of a more experienced developer isn't avoiding errors entirely, it's reacting to them constructively.

Understanding the problem

Make sure you stop and understand exactly what went wrong before you start trying to fix it. Otherwise you might go down an entirely wrong path, which will make it harder to figure out what the real original problem was later.

What were you actually trying to do? Do you have a good idea in your head of what the code you wrote should do? If you're working on a specific project feature or workshop problem make sure you've read it properly and understood the edge-cases. If you're following some documentation make sure you've re-read exactly how it works.

E.g. What arguments does this function take? What type of thing does it return? Is it asynchronous?

Read the error

It can be overwhelming to have 50 lines of error message dumped into the console. It's important to stay calm, take a deep breath and read what it says. Error messages are usually quite useful, as long as you know where to look (hint: start at the top).

Try to figure out where the error is coming from. Sometimes there will be unrelated logs you need to ignore from tools like npm. Find the part that looks like the real error message (this gets easier with practice).

JavaScript errors generally consist of an error type, an error message, then a stack trace. Let's look at an example error and break it down:

Uncaught TypeError: arr.join is not a function
    at arrayToString (index.html:11)
    at run (index.html:14)

The first part tells us that our code encountered a "type error". This means we tried to use a value in an impossible way. E.g. accessing a property on undefined instead of an object. This is probably the most common cause of JS errors and is worth eliminating as a possibility before moving on.

The second part tells us we tried to call the .join() method of a variable named arr, but it was not a function (and so could not be called). Since .join() is a built-in method (and therefore all arrays will have it) this probably means arr is not actually an array.

Finally the stack trace shows us all the function calls that led up to the error. Here we can see the error occurred in a function named arrayToString, within a function named run. The index.html:11 tells us the error occurred on line 11 in the index.html file. Most browsers allow you to click this to jump straight there.

Google the error

If you can't figure out what's wrong from the error message/looking at your code your next step should be to search for the exact error text on Google. You can put a search term in quotation marks to force Google to show you exact matches.

Learning to craft searches that return the most useful results is one of the most important skills to grow. As well as searching for the exact error message you can try including keywords for more context, like "JS", "npm", "React" etc. You can also limit your search to specific sites by adding their domain, e.g. "site:github.com".

Ideally this will return GitHub issues on the repo for the library you're using, or Stack Overflow questions from people who had the exact same problem. Try to prioritise recent stuff, since the JS ecosystem moves very fast. Usually a 2 year old issue won't be relevant anymore.

Ask an AI

It's a brave new world. Try some prompt engineering and give Chat GPT a go. But be warned that these pre-trained transformer models have no idea what they are talking about and are (as of writing) prone to the occassional very lucid and convincing hallucination, so take any responses with a pinch of salt.

Fixing the problem

Once you understand what's wrong you need to fix your code. If you found an easy solution to your problem this might be simple, but sometimes it will require experimentation.

Make sure your code is running

Always check that the code you think is executing really is. It's surprisingly common to be refreshing the deployed production site wondering why your local changes aren't showing up.

Make sure the function you're changing is actually getting called, and if there are any branches in logic (e.g. if statements) that you're in the one you expect. This can be as simple as including a console.log("here!"), or as complex as stepping through your code using your browser's debugger.

Change one thing

The biggest mistake beginners make when trying to fix a problem is changing multiple things at once. As with scientific experiments you should only ever change one thing at a time. This ensures that you know exactly what change was the right one.

This is a common issue when debugging CSS—you keep piling rules on until the page looks how you wanted, but you actually only needed one of the five you added. You'll probably have the 4 unnecessary rules in your code forever.

Track attempted solutions

If you end up working on a more complex problem for some time it's worth keeping track of things you tried that didn't work. This will be helpful if you have to hand it off to another developer in your team, or ask someone else for help. It's frustrating for both you and them if they end up doing something you already tried.

Ask for help

If you're totally stuck and can't find anyone else with the same problem online it's time to ask for help. The best person to ask is a team member, since they have all the context required for working within your codebase.

If you have access to a more experienced mentor that can be very helpful. There are whole classes of problem that are trivial once you've seen them a couple of times but almost impossible the first time you see them.

Finally you can try asking online. Stack Overflow can be quite hostile to new posters (they have pretty strict guidelines you're supposed to follow), but you will probably find someone who can fix your problem. If your issue is with a third party library you could ask on GitHub or (for bigger libraries) their online community (usually Slack or Discord).

Learning how to ask for help is important. Every developer needs help at some point, especially when they're learning new things. By structuring your question effectively you can make it easier for people to help you, and increase the likelihood of solving your problem.

Quick summary

Here are the steps to follow when asking for help. More detail is provided below!

1. Try to debug on your own

2. Google the problem

3. Describe the problem and what you've tried

4. Make sure to include a code sample

5. Update with the solution

When to ask

Make sure you've tried to solve the problem on your own first. Often it can be as simple as a typo, or forgetting to save your changes—it's best to ensure you really have a problem before involving someone else. Make sure you have at least googled your problem!

The amount of time you spend trying to solve the problem should be proportional to how much time you have. If you're doing a 1 hour workshop then spending 15 minutes stuck is a bad use of your time. You should probably ask for help after 5 minutes. However if you're on a 2 day project you should spend more like 20 minutes searching for your own solution.

It's important to develop your problem-solving and debugging skills. If more experienced people always tell you what's wrong then you'll struggle later in your career. Read the debugging guide for more information on solving code problems.

How to ask

Once you're sure you have a problem you cannot quickly solve on your own you should post a message asking for help in the appropriate channel. This could be your cohort's #help-and-solutions Discord channel, or the more general #facoverflow, or even somewhere public like Stack Overflow or a project's GitHub Discussions.

Describe the problem

A good message should describe the problem, and especially what you want to happen. Often people describe a specific syntax issue, when really their problem is with their whole approach. For example for "how can I swap two numbers in this date string?" the most helpful solution might be "use the built-in date internationalisation method instead".

You should also include anything you have already tried. That way someone helping you can skip over solutions that you already know won't work.

Include some code

Make sure you include a code sample. That way somebody can try to help you straight away, without having to ask you questions and wait for responses.

You can copy/paste the relevant code if it isn't too complicated, but try not to dump an entire 100+ line file onto someone who has never seen it before. If your code is very complex try to provide a simplified example of what you're trying to do.

Make sure your code is syntax-highlighted (if the platform supports it)! For example on Discord and GitHub you can use three backtick characters to create a code block. Put the name of the language you're using on the same line directly after the backticks to get syntax-highlighting. E.g. this:

```html
<h1>Hello world</h1>
```

will produce something like this:

<h1>Hello world</h1>

If your project is on GitHub then consider linking directly to the lines of code in question. You can do this by clicking the line number on GitHub. Make sure you have pushed your latest work to a branch so it's up-to-date.

Stay engaged

This one is important. Don't ask for help and then disappear. Make sure you keep an eye on any followup questions that may get asked. It's hard for a mentor to help if they can't get additional information out of you.

It's also very frustrating as a mentor to suggest a potential solution and then never hear back. It's okay to be busy on a project, but try and provide a quick update like "thanks, it worked!" or "thanks, the problem was actually xyz instead".

This is not only good manners but also helpful for anyone else reading who may have a similar problem—having a solution confirmed or not could save them lots of time.

Reading other people's code is a good way to learn. You gain insight into how other people solve a problem, and you see what makes code readable and understandable to you.

While it may feel like the focus of the course is on writing code, programmers generally spend more time reading it. Remember the target audience of your code is other humans, not the computer.

How we code review

Before code review

Make sure your own project is ready to be reviewed:

• Push the latest changes to GitHub

• Make sure the code you want reviewed is merged into the main branch

• Deploy the latest version so it can be viewed online

• Make sure there's a README.md that describes the project

  • The readme must contain instructions on running the project locally

  • If there are required secrets share them privately with your cohort

Do not work on your own project during code review time.

This makes the team you're reviewing miss out on valuable feedback, and it's hard to review your code if it keeps changing.

The reviewing process

You'll be swapping with another team. They review your project and you review theirs.

• Open the repo on GitHub and read the readme

• Open the deployed version and play around with the UI

• Does the project meet the user stories for that week?

• Does it demonstrate the learning outcomes for that week?

• Can you see any obvious bugs or areas to improve?

• Clone the repo and follow the instructions to run it locally

• Does everything work as expected or were there missing instructions?

• Open the project in your editor

• Does the file structure make sense?

• Can you you follow the different paths the code might take?

• Do variables and functions have clear and descriptive names?

• Do you understand the code?

Raising issues

• Check if the issue you want to raise already exists

• Use the search bar if there are lots of issues already

• Make sure your issue titles clearly summarise the content

• Embed the code you're discussing in the issue

• Link to relevant documentation if you reference unfamiliar concepts

• Make your issues are clear and actionable

• Don't focus on subjective preferences like "use more line breaks"

• Focus on code that confused you, or might break unexpectedly. E.g. "I wasn't sure what x was, could you call it descriptiveName instead?"

• Ask questions about things you didn't understand

Don't feel like you have to look at all the code that's written. Take your time exploring fewer things in more detail.

Review etiquette

• Phrase your issues in an open-minded way; seek to understand

• Don't assume you know better–you're missing the original context for why they wrote it that way

• If you think you know a better way of solving a problem, phrase the issue as a question. E.g. "Would using a here instead of b be better because of xyz...?"

• Issues don't all have to be negative: if you spot something clever or elegant leave a compliment!

When receiving reviews try to remember that the reviewer has your best interests at heart. They want to help you become a better developer, so assume they have good intent. You are not your code.

• Groups of three

• Each session lasts for 75 minutes

Allow 3 minutes at the beginning and end of the session for a quick check-in and check-out from each member of the group.

It is not necessary (or even important) to finish each challenge. It is more important for the group members to establish a rapport and to get to a point where they understand each problem and are working towards a solution.

An inexperienced group can be led by a facilitator, who can ensure that everyone understands their roles and can offer their meta-observations (an observer watching the Observer!).

Schedule

• 00:00 Check-in

• 00:03 Establish roles

• 00:05 Round #1

• 00:25 Round #2

• 00:45 Round #3

• 00:65 Group reflection

• 00:70 Check-out

• 00:75 End

Two different modes

A coaching group can work as:

1. A forum for group members to get support on a problem they have been working on; or

2. An opportunity for group members to set challenges for each other as a way to get experience of responding to each other under mock interview conditions.

The roles

Proposer

The proposer shares their screen and presents a challenge which is then discussed with the respondent. Depending on the context, this will either be:

1. A problem that they want help with; or

2. A problem that they have prepared to test the knowledge of the Respondent.

Respondent

Depending on the context, it is either the Respondent's role to:

1. Support the Proposer to find a solution to their challenge; or

2. Take the lead in finding that solution.

In either case, they should start by ensuring that they fully understand the challenge being presented by reading or describing for the whole group the information they see on the Proposer's screen.

The Proposer and the Respondent are effectively pairing on a problem together, with one taking the lead with the problem solving. The person in the supporting role should focus on asking questions of the person in the leading role, rather than directly providing solutions, with a view to the whole group gaining a better understanding of the problem.

Observer

The Observer is responsible for providing constructive feedback to both the Proposer and the Respondent at the end of the round. Was the person in the supporting role supportive and did they at any point step out of role and offer solutions? What was missing from the eventual solution that either the Proposer or the Respondent missed?

It is also the Observer's role to keep time and allow time for their own feedback at the end of the round.

Starting

After checking-in, the group can agree on their roles for the first round.

Ending

At the end of the third and final round, the group can take 5 minutes to offer final reflections on each of the rounds. If the group is reporting back to a larger group, then each person can rehearse a 20-second reflection from the Observer's point of view, before checking out.

Tools

• Question crib sheet, that each respondent can use as a scaffold for their questioning;

• Glossary of terms.

We are committed to creating an inclusive, diverse and equitable learning environment where everyone feels valued and respected.

We believe that diversity is our strength, and that by embracing the differences of our people, we can create a more innovative and productive learning environment.

Our Values

Our values of respect, inclusion, and equity guide our commitment to diversity and inclusion. We believe that:

• Everyone deserves to be treated with respect, regardless of their race, ethnicity, gender, sexual orientation, disability, age, religion, or other personal characteristics.

• A diverse group is a stronger group. We are committed to creating an environment where people from all backgrounds feel welcome and valued.

• Everyone should have the opportunity to succeed. We are committed to providing equal opportunities for all learners, regardless of their background.

Our Commitments

We are committed to the following:

• Providing an environment free of discrimination and harassment. We will not tolerate any form of discrimination or harassment, and we will take swift action to address any incidents that occur.

• Promoting diversity and inclusion in our hiring practices. We will actively seek out and recruit people from diverse backgrounds into our cohorts.

• Creating a supportive and inclusive learning culture. We will curate groups and guide our learners to understand and celebrate diversity.

• Measuring our progress and holding ourselves accountable. We will regularly assess our progress and make adjustments as needed.

Set up

• Groups of 4. Typically, lasting 90 minutes, with four 20-minute rounds;

• Start with a check-in and end with a check-out;

• Inexperienced groups should have a facilitator present.

Roles

• Proposer: presents a problem;

• Respondents: the rest of the group.

Rounds

• The proposer shares their screen and presents a problem which is then discussed by the group;

• In turns and for no more than 5 minutes each, each respondent leads the discussion by asking questions of the proposer and the rest of the group with a view to the whole group gaining a better undertanding of the problem;

• If there is a facilitator present, then after each of the respondents has led the discussion, they can add their own reflections. They should also make sure the group is on schedule. If there is no facilitator present, the group can nominate a timekeeper for each round;

• When the round comes to an end, the next group member takes on the role of presenter and the process is repeated until each member of the group has presented.

Aims:

1. To give each participant an opportunity to get the support of the group with a problem that they are working on;

2. To give each participant practice in developing questioning strategies to aid problem solving;

3. To give each participant practice at communicating proposed solutions;

4. To give each participant practice at thinking reflectively about their learning processes;

5. To ensure that each participant gets an equal opportunity to develop their problem-solving skills;

6. To develop the capacity of all participants to run a strucutured study group without a facilitator present.

Tools

• Question crib sheet, that each respondent can use as a scaffold for their questioning;

• Glossary of terms.

Most of the mentors you will interact with on the course have recently graduated from the course. Some mentors will be alumni who finished the course a little while ago.

The types of mentors you'll meet are:

• Week mentors

• Project mentors

Week mentors

1. Cohort alumni who recently completed the course.

2. Join workshop discussions and provide support during projects.

3. Offer guidance without giving direct answers.

4. Share experiences, debugging advice, and tips for maximizing the course.

Project mentors

1. Support during final project(s).

2. Can be FAC alumni or apprenticeship employers.

3. Provide technical advice on tech stack choices and recommended libraries.

4. Not available for day-to-day debugging; use available resources like StackOverflow, cohort members, and the FAC community.

5. Schedule specific slots to discuss project-related matters.

6. Responsible for reaching out, scheduling time, and clearly communicating support needs.

Preparation

A one-day project needs as a minimum the following:

• One clearly-defined topic

• A well-defined task (or tasks)

• Links to relevant resources

The topic will usually be around a specific language, library or technology, such as Docker, D3, Elm, or TypeScript.

The task (or tasks) needs to be something that can reasonably be completed in 5-6 hours.

The resources need to be well-researched learning materials that will provide a sufficient introduction to the topic.

Facilitation

A well-prepared project day does not need a facilitator, but facilitating them can be fun.

Facilitators may:

• Prepare an introduction to the topic or do a workshop or code-along at the start of the day;

• Make themselves available (either in-person or online) to support the teams while the task is being worked on;

• Participate in the project presentations at the end of the day.

Teams

By default, work in teams of 4. Larger teams are more likely to be self-contained and not need too much support.

Presentations

One hour before the scheduled end of the day, all teams take it in turns to present their work.

For the in-house presentation, your CF will be providing you with feedback.

Grading

For each criteria, you will be rated as:

• 5 = Far exceeds expectations

• 4 = Exceeds expectations

• 3 = Meets expectations

• 2 = Development required

• 1 = Improvement required

Technical Learning Outcomes

The learning outcomes are assessing TECHNICAL skills and we have provided some guidance for how to evidence that you have met these in each role.

QA Guidance:

1. Use a testing framework, demonstrate testing and monitoring of code coverage

   • Include screenshots of tests and code coverage using testing framework

   • Explain test coverage reports generated by these tools

2. Produces clean and legible code

   • Include before and after snapshots of code that has been refactored for readability and maintainability.

   • Discuss practices they have adopted to ensure code cleanliness (like code reviews, linting, formatting standards), how they have refactored complex code, and the impact of these practices on the project's maintainability and readability.

DevOps Guidance:

• Set up deployment and take ongoing responsibility

  • Include screenshots of the deployment pipeline configuration files or a live demonstration of the deployment process.

  • Discuss the deployment strategy, choice of deployment platforms (like Heroku, AWS, Netlify, etc.), and any scripts or tools used to automate the deployment process. They should also cover how they manage ongoing updates and rollbacks if necessary.

Scrum Facilitator Guidance:

• Sprint planning

  • Prioritise issues

  • Break down larger issues into manageable chunks

  • Show us your project board, talk through it

  • How was the assignment of issues decided on?

  • How was progress tracked and the board updated?

  • Show us an issue that needed adjustments (was it reassigned? Was it deferred by a change in the sprint plan? etc…)

• Lead Sprint Review

  • Show us data on your velocity

  • Talk us through your retro (what findings came of it? How are you adjusting for the next sprint?)

UX Lead Guidance:

• Advocate for the user

  • Show us your prototype

  • Explain how the design responds to feedback from your user testing

  • Show us how some features came to be prioritised over others and how that decision accounted for the impact on the end user

• Create a style guide

  • Show us your style guide

  • Tell us how it was reinforced during the project

  • Tell us how this style guide contributed to the readability and scalability of your codebase

• Lead on project documentation

  • Show us your project documentation

  • Talk through the different sections of your documentation

  • Talk through how a new developer can use this documentation to understand the needs of the codebase

Employability-based Learning Outcomes

The learning outcomes are assessing EMPLOYABILITY SKILLS and we have provided some guidance below for how to meet these expectations.

Note: They may be harder to demonstrate within the presentation itself, but for these criteria your grade will be based on how you have engaged with the entire project.

• Works independently and takes responsibility to solve problems on their own.

  • Include: Examples of how you addressed any problems that arose

• Communicates effectively in a variety of situations to both a technical and non-technical audience.

  • Ensure: When preparing and delivering the presentation, ensure that it is accessible to all stakeholders and that any technical terms are clearly defined at the beginning

• Works collaboratively with a wide range of people in different roles and acts with integrity

  • Assessed over the course of the project based

Pair programming is working together on one laptop, or one feature together. When pairing, it's important for both developers to feel comfortable and able to contribute.

When to pair

When you're working through workshops in class time, and during your projects. When you start work with your employer, you'll be likely to be pairing for a decent chunk of your time.

Methods

There are a thousand ways to work together. Figure out what works for you, and communicate with your partner about that to find a balance that works for you both.

Here are some suggestions for how you might work together:

Ping pong. Take turns writing code. How much code you write depends on the context. Maybe, one developer writes a line of code and then the other writes a line of code. In another case, one developer starts by creating a single failing test and then each developer takes it in turns to first write code to make the test pass and then to write a new failing test before passing the keyboard back to their partner. On your projects, you might extend this, perhaps by writing for 10 minutes and then swapping who is 'driving'

The back-seat driver. One developer shares their screen and follows the instructions of the other developer. The person 'driving' is the one typing and should follow exactly the instructions of the 'navigator'. If the navigator is lost and would like a suggestion, they can ask the driver where they think to go next or suggest somewhere to look online for a solution.

Tips and Tricks

Getting better at pairing, is not just about being better at writing code. Develop your verbal communication. It’s hard to work with someone if they don’t verbalise their thoughts/reasoning and if there’s no dialogue between the two of you when typing. When pairing, both developers should be active and neither should be a shadow to the other.

It's important to switch roles, don't let one person do all the coding. You get more out of it by getting stuck in. Switch regularly and give the other person time to read through the code base before they take over. Being able to talk though someone else's code is a vital skill to have and will enhance your understanding.

If pair-programming remotely, weigh up your options with care. Screen-sharing guarantees that you’re both looking at the same piece of code together, but puts the power to change that code in the sharer’s hands alone. VSCode also allows Live Share, where both programmers can type at once. This can be more dynamic, allowing faster corrections to code and letting the second programmer view other parts of the codebase easily, which can be helpful when you need to follow the trail of a function across different files. Without clear communication, Live Share can become chaotic, even more so if one or more parties has connection issues.

This guide will explain how to install all the software you need to start the course.

Before you start you should read the guide to make sure your computer is appropriate. This is especially true for Windows users, since you'll need a Linux environment for most of this guide to work.

If you hit any problems check the .

Package managers

We'll be using a "package manager" to install most things. Package managers are software you use to install other software. They make it easier to install lots of things at once and keep track of everything you have. This is a more structured way than just going to a website, finding the right link and downloading an installer.

Linux

If you're using Linux (even on Windows) you should have the apt package manager already, since it's the standard way to install things on most Linux distributions.

macOS

Macs don't come with a package manager, so you'll need to install before anything else.

The software

Here's a quick summary of the things we need. We'll cover what each one is and how to install it below.

• Git

• Node

• npm

• iTerm2 (Mac) or Windows Terminal

• VS Code (or your preferred editor)

• Chrome/Edge/Firefox

Git

If you need to install Git you can use your package manager.

Mac

Linux

Configuring Git

Node

Node is a version of JavaScript that you can run on your own computer. JS is usually limited to running on web pages inside of a web browser, but Node lets you run JS code anywhere.

You don't want to install this with a package manager, since it's a language not a normal program. Most package managers have out-of-date versions.

Volta

You may have to restart your Terminal afterwards.

You can now use Volta to install different versions of Node. We require Node version 18 for our programme, so you need to specify that:

Volta should install Node 18 and automatically start using it. You can check it worked by running this command:

npm

npm is yet another package manager (it stands for "Node Package Manager"). It's used for installing JavaScript code inside your projects. Luckily npm comes with Node, so you don't have to install it.

If for some reason you don't have it, or it is very out-of-date, you can install it with Volta too:

Terminal

Mac

Windows

Code editor

You may need to install the "command-line tools". This allows you to run code . in your Terminal to open the current folder in your editor (this is very useful!).

Try running code --version. If you get an error you need to open VS Code, hit cmd-shift-p (or ctrl-shift-p on Windows/Linux) to open the command-palette, then search for “shell”. Select the option that says: Shell Command: Install ‘code’ command in PATH.

Web browser

It's a good idea to have a few different browsers installed for testing your websites, as they don't always work in exactly the same way.

Checking everything

You can run our installation checker script to make sure everything is installed correctly:

This will tell you what version (if any) you have of each required program. You want at least these minimum versions: Node 18, npm 8.

Troubleshooting

Every computer is different and has a different combination of operating system, version, etc. This means it's likely you'll encounter some problems installing at least one thing. This can be frustrating, but try to take a deep breath and work through the issue.

The most important skill to learn as a developer is how to carefully read an error message and figure out what went wrong. So in a way fixing problems at this stage is great practice starting out in your career!

General steps

1. Read the error message. If it's very long make sure you scroll right to the top.

2. If the error message suggested a solution try that first. If it pointed out an obvious issue (like a mispelled command) try correcting it and running again.

3. If the error isn't self-explanatory google the exact message plus the general technology. For example is Homebrew fails to install with a message like Failed during git fetch... then search for Homebrew "Failed during git fetch". The quotes tell Google you want the results to include that exact string.

4. Don't be afraid to try suggestions off the internet. You'll find yourself copy/pasting things from Stack Overflow throughout your career. However bear in mind that Terminal commands can be dangerous, so be a little cautious and make sure you read things before blindly pasting them.

Known issues

Some problems come up again and again, so it's quicker to list them here than have everyone google them.

Volta command not found

Did your Volta install script succeed, but you cannot actually use it (e.g. you get Command not found when running volta install node)?

This means the Volta program was not added to your Terminal's PATH variable. PATH is a list of every command-line program that is installed. It's where your Terminal looks for available commands whenever you type anything (e.g. ls and cd are listed inside PATH somewhere).

Volta is supposed to automatically do this, but sometimes it does so in the wrong config file (e.g. if you have both Bash and Zsh configs). You can manually add the required lines. First determine which shell you're using with:

This will print something like /bin/zsh or /bin/bash. If your shell is Zsh (the default on modern Macs) then you want to edit the .zshrc config file. If it is Bash you either want the .bashrc or .bash_profile config files.

These config files live in your "home directory". The tilde symbol (~) is a shortcut for this directory. You can list everything inside of it with:

You should be able to see the config file you need in there. Open it in your text editor with:

and add the following lines (there might be existing config; you can add these lines anywhere):

Restart your Terminal and you should now be able to use the volta program.

Homebrew failed git fetch

Homebrew uses Git to download all of the information it needs about packages. This homebrew/core repo is very big, and can fail to download. You may see an error like:

This usually means the download was interrupted midway through. You can try re-running the same command in case it was a fluke. However we've found that some Internet Service Providers enable "protection" settings that mess with large Git downloads.

The easiest way to verify this is to tether your laptop to your phone's hotspot and retry. If that works you may want to investigate your ISPs settings and see if there's something you need to disable.

A good GitHub workflow is essential to keeping a project organised and easy to maintain. The larger the project, the more important it becomes to track changes and be aware of who worked on what.

Some things to keep in mind:

• Make sure everyone has the same code formatter () set up, so you can avoid merge conflicts due to weird spaces/extra commas etc.

• Never work on the main branch. Before you start work, make sure you pull main and create a new branch.

• Commit often. This makes it easier to undo specific changes.

• Write meaningful commit messages. A good convention to follow for commit messages is that they should be imperative, i.e: "add tests for signup form"

• Your commit messages should make sense if read in this format: "If applied, this commit will: <your commit message>"

• If you've been coding for half a day and forgot to commit, VSCode lets you from the source control panel.

• When you pair, don't forget to co-commit! (you can find more information in the )

• When you finish working on your branch, make sure it's up-to-date with main before pushing

• , and close issues as you finish working on them.

• Review PRs as a team, and merge together. In smaller weekly projects where there isn't time for code review on every PR, make sure the other pair has seen your work and any implications it has on their code.

A guide to leading and supporting peer learning using

This is a live document that mentors are encouraged to feedback on.

Please read these notes and check with the course facilitator before your week starts with any clarifications, questions and/or thoughts.

Before Your Week:

1. Ensure Ownership: Make sure you are an owner of the cohort's GitHub organization.

2. Familiarize Yourself: Read the workshops, solutions, project details, and learning objectives for your week. Note any changes made since your cohort started.

3. Communicate with the Course Facilitator: Check in with the course facilitator for support before, during, and after your week.

During Your Week:

1. Delegate Responsibilities: Decide who will lead specific portions of your week. Refer to the day-by-day checklist for a detailed breakdown.

2. Review Recent Projects: Take a look at the cohort's most recent projects and inquire about any relevant feedback from the previous week's SGC (Student-Generated Content).

Additional Preparation:

1. Understand Cohort Expectations: Read the cohort expectations document located at GitHub > fac# > cohort > expectations.md.

2. Read User Manuals: Familiarize yourself with the cohort's user manuals. Access them as raised issues on GitHub > fac# > user-manuals.

Being a Good Mentor:

1. Share Experiences Mindfully: Avoid creating unnecessary expectations based on your own experience. Frame your experiences as such and only share when directly asked.

2. Avoid Negative Opinions: Refrain from dismissing or criticizing course material. Present the curriculum and allow learners to form their own conclusions.

3. Empower Through Questions: When approached with a problem, ask questions to guide learners in finding the answer themselves.

4. Focus on the Problem, Not the Solution: Encourage learners to explain the purpose behind their actions and focus on the problem at hand rather than the specific solution.

5. Encourage Collaboration: Suggest seeking input from team members or other teams who have encountered similar problems.

6. Visualize Solutions: Keep a notepad and pen ready to visually aid explanations by drawing out problems and solutions.

7. Embrace Not Knowing: If you don't know the answer, admit it honestly and collaborate with learners to find the answer together.

8. Break Down Big Problems: Help learners tackle overwhelming tasks by breaking them down into smaller, manageable steps.

9. Allow Room for Mistakes: Let learners stumble and learn from mistakes. Provide support and encouragement during their problem-solving journey.

10. Embrace Different Approaches: Avoid immediately rejecting learners' methods. Be open to the possibility that their way could be right. Ask them to explain their steps to foster learning.

11. Collaborate with the Cohort: Work with all members of the cohort and encourage those who understand a concept to assist others.

Note: learners may initially expect you to have all the answers, which may lead to frustration. Clarify your role as a mentor and emphasize working through problems together.

What you will do through the week

Monday

• Join the conversation with the cohort about the previous Friday's Workshop

• Introduce the Project and Spike - share your experience of how that project went for your cohort.

Tuesday

• Join the Zoom call in the morning and check in on the teams every 30/45 minutes to address any questions or concerns they are having throughout the day.

Wednesday

• Work your way around the room and ask the teams if there is anything they need help with.

• At the end of the day you will be doing a code review of the two teams. It is best to spend 30 minutes on one and then move onto the other team.

Thursday

• You do not come in on Thursday

Friday

• You do not come in on Friday

Reading a function

1. Where are the inputs (or arguments or parameters) to the function?

2. Can you see any clue as to what type of value the function takes as arguments?

3. Where is the output (or return value) of the function?

4. Can you see any clue as to what type of value is being returned?

5. If a variable is returned, where is it first defined?

6. If a variable is returned, where is it updated after it is first defined?

7. Where are the function arguments used inside the body of the function and how are they used?

8. What other variables are declared inside the function; where and how are they used?

9. Can you see any other clues as to what the function is doing?

10. If you call the function with some test values, what is returned and what does that tell you about the function's purpose and the types of its arguments and return value?

11. Can you think of a real-worl use for this function?

Writing a function

1. Can you put into your own words, what this function is supposed to be doing?

2. If a function outline is provided, can you describe what each part of the outline is doing;

3. What is a sensible name for this function?

4. What type of value does this function return?

5. What arguments does this function need to produce a meaningful output?

6. Have the arguments got sensible names?

7. What methods could you apply to the arguments to get the required output?

8. How could you break this problem down into smaller parts?

9. If tests are provided, what happens when you run the tests and can you explain what each of the test results mean?

10. If tests are provided, could you amend the return value to pass the first test?

11. And subsequent tests?

12. If you are getting error messages when running the code, what are the eror messages telling you?

The apprenticeship is assessed in two ways:

• Project (“Work-based project with questioning”)

• Portfolio (“Professional discussion underpinned by portfolio”)

During the 12 week training, we'd like to give you some opportunity to feel prepared for these. Your Project is completed at the end of the apprenticeship, during EPA gateway. The portfolio must be submitted in order to enter gateway.

Portfolio evidence

The portfolio is a collection of documentation which evidences the work you've completed throughout your apprenticeship. The documentation should describe projects you've worked on and include detail about your contribution to those projects.

Each piece of documentation will cover:

• WHAT you did

• HOW you did it

• WITH WHOM you did it

• WHY you did it that way

Mapping

Separately, you will create a document which maps your portfolio evidence to the Knowledge, Skills, and Behaviours (KSBs) detailed in the apprenticeship standard.

The document should contain a table which maps KSBs to your evidence, like so:

During the training

While on the full-time training, you'll have time to practise gathering portfolio evidence and mapping to KSBs. For each of your weekly projects, create documentation of what you've done, how you've done it, with whom, and why you made those technical choices. You can write this documentation as your README, or into a separate portfolio.md file.

To see the full list of KSBs for the project, visit our apprenticeship standard site.

For your final projects, both in-house and Tech for Better, you'll write a detailed README on the project.

The following sections are required. Your report is supposed to demonstrate a certain set of knowledge, skills and behaviours. These are listed alongside the relevant questions as quotes.

Introduction

• What are you building?

• Why are you building it?

Project scope

• What are you not building?

• How did you decide what features were important?

Project plan

• How are you going to structure your sprints?

• What order are you going to build in?

• How did user research inform your plan?

Requirement analysis

• How will you ensure your project is accessible to as many users as possible?

• Are there any legal or regulatory requirements you should consider?

Project learnings

• Did your team work effectively?

• What would you do differently next time?

Research and findings

• What did you find out from user testing?

Project outcomes

• Were your assumptions right or wrong?

Recommendations and conclusions

• What features would you prioritise to build next?

• Was the project a success?

Software Development Lifecycle stages

Planning

• What roles did your team take on?

  Explain the roles and responsibilities of all people working within the software development lifecycle, and how they relate to the project (K2)

• Did these roles help your team work effectively?

  Outline how teams work effectively to produce software and how to contribute appropriately (K6) Compare and contrast the requirements of a software development team, and how they would ensure that each member (including themselves) were able to make a contribution (K6)

Analysis

• What might be the intended and unintended consequences of building this product?

Design

• How did you plan a user experience?

• What technical decisions did you make?

  • Server-render vs client-render vs both

  • Relational or non-relational or no DB

  • Self-hosted or platform-as-a-service

  • Frontend first vs DB first

• Did you create a technical specification?

  Review methods of software design with reference to functional/technical specifications and apply a justified approach to software development (K11, S11, S12)

Implementation/Build

• How did you ensure your code was good?

  Create logical and maintainable code to deliver project outcomes, explaining their choice of approach. (S1)

• What interesting technical problems did you have to solve?

  Outline and apply the rationale and use of algorithms, logic and data structures. (K9, S16)

• How did you debug issues that arose?

  Apply structured techniques to problem solving to identify and resolve issues and debug basic flaws in code (S7)

Test

• How did you verify your project worked correctly?

  Identify and create test scenarios which satisfy the project specification (S6)

• Did writing automated tests catch any bugs?

  Analyse unit testing results and review the outcomes, correcting errors. (S4)

Deploy

• Where/how did you deploy your application?

  Review and justify their contribution to building, managing and deploying code into the relevant environment in accordance with the project specification (S10)

• What problems did you encounter during deployment?

Maintain

• Is it easy for someone make changes to the codebase?

• Could a new person quickly be onboarded to contribute?

• Establishes a logical thinking approach to areas of work which require valid reasoning and/or justified decision making (B2)

• Describes how they have maintained a productive, professional and secure working environment throughout the project activity (B3)

Your timetable includes time allocated for your team to write your presentation and discuss how you are going to present your project together.

Remember: We want to hear from everyone during your presentation!

Each team then has 12 minutes to present, with 5 additional minutes for questions. Depending on team size, this means each person has about 3/4 minutes of speaking time. We will be strict with you on timing, so make sure you use your time effectively.

Structure

1. Show your process:

   • Talk through the Why, What, How of your project

   • How did your team split up the work?

   • How did your team choose to pair? How often did you swap pairs?

2. Briefly demo your project and explain how it conforms to your brief i.e. the user stories and acceptance criteria

3. Talk about each project role, and how you divided up the work.

4. Show your project board and (from Week 2) report on estimated vs actual velocity

5. Walk us through your code. Emphasise the things you learnt that were new to you, which the rest of your cohort could benefit from hearing about:

   • something you're proud of

   • something that you found really hard / struggled with

   • anything you don't understand yet, or don't understand fully

6. Have the people who didn't write a piece of code talk through it - this is a great way to demonstrate knowledge of learning and collaboration. Your whole team should be able to explain the whole codebase - in other words, everyone is responsible for writing code the whole team understands.

7. Avoid talking through the project brief for a long time - each team has the same brief and your time will be better spent talking about what was unique about your presentation

8. [From week 4 onwards] talk about which KSBs you've met in your projects that week

Preparing for presenting

Your team should spend some time preparing what you'll present. Alongside creating a slide deck, this means preparing which parts of the presentation you'll each talk through and ensuring your presentation fits within the time available.

Decide together which sections each person will talk through. Who will share the screen for the demo? Who will talk and who will click through? Choose someone on your team to keep time for the team.

Spend some time revisiting your codebase and understanding the code. Are there sections which you couldn't talk about? If so, spend time reading through the code together to ensure you are all on the same page, especially for code you didn't write yourself. Everyone is responsible for this.

Make it interactive

• Ask your audience questions and keep them on their toes.

Include code snippets

• But keep them concise!

• We want to hear about something novel in your project, give the audience an understanding - without overwhelming them with line by line detail.

... and use gifs

• Jazz it up with emojis, images and gifs!

Scrum(TM)

Scrum is a widely-used software development method, that organises work into sprints. A sprint is a fixed period of development time during which the team will not respond to new change requests.

Two weeks is typical in the industry. During the pre-apprenticeship we will work in one-week sprints. During the full-time programme, each week we are going to do a single two-day sprint. For your final project, you will be doing one-week sprints.

User stories

A user story is an action that a user wants to perform. Usually, they are written in the form:

"As a... I want... So that..."

Estimate

The difficulty level of a user story, expressed in points.

CONTROVERSY ALERT: Some people prefer to estimate in absolute time, expressed in hours or half-days, but in order to develop a good sense of relative time, we will estimate our user stories in points.

Estimates

• E1 - Short story, estimated

• E2 - Story, estimated

• E3 - Long story, estimated

• E5 - Extra long story, estimated

Actuals

• A1 - Short story, actual

• A2 - Story, actual

• A3 - Long story, actual

• A5 - Extra long story, actual

Velocity

The team capacity, expressed in points, for each sprint.

Backlog

All uncompleted user stories are listed in the project backlog. Each week, during sprint planning the team reprioritises user stories and agrees the next sprint backlog. The sprint backlog is then a prioritised backlog of all the user stories that we estimate will be completed in the next sprint.

Sprint retrospective

At the end of the sprint, the development team will hold a restrospective. On our full-time programme, we run these in the form of a stop, go, continue.

Sprint review

On projects which are longer than one sprint - the team will compare how many story points they actually completed in that sprint with how many they estimated that they'd complete. This informs estimations for the next sprint.

Project board

A Kanban board can be used to track progress on your project. With labels for estimates and assignees for each issue.

The Kanban columns are usually something like:

• backlog

• stretch

• todo

• doing

• done

Zero-point issues

Not all issues raised in the project board contribute to the velocity estimate. Chores, bugs, refactors and spikes are all zero-point issues, even though they will (seriously) impact your sprint velocity.

• Chore Something that needs to be done, not directly related to a user story

• Bug Something broken

• Refactor An improvement to the code that delivers no change to user experience

• Spike Researching a potential solution to a problem by creating the simplest possible implementation of it

CONTROVERSY ALERT: Some people prefer to estimate chores, bugs, refactors and spikes just like user stories, however they might better be thought of as non-negotiable and therefore outside the scope of the sprint planning process.

Labels

Labels can be added to issues to give a clearer indication of the time estimate, the actual time that was needed, and what part of the project the issue relates to.

Role Circles are a chance to chat to members of other project teams, grouped by your responsibilities to your own team. In the past, we've found that teams often encounter the same issues and that it can be easy to feel siloed in your own team.

Structure

Role circles last for 15 minutes. Everyone in the group should get the opportunity to speak. You may prefer to nominate a facilitator at the beginning of the session.

Focus

Focus on the challenges of the project related to your role. For example, if your role is Deployment you might like to discuss the architecture of the project. As a group of facilitators, you might like to discuss how you'll ensure everyone in your group is able to meet the week's learning outcomes.

Each week the challenges and focus of the project will change. Use this discussion as an opportunity to understand and share concerns and ideas across teams.

While working in project teams of four, you will each pick one of the roles below.

We have listed a set of responsibilities for each role - but do keep in mind that your main role on the project is as a developer. The project roles are areas of focus that you should ensure get done as a team

For example - If you are the UX Lead, do not feel obliged to do all the CSS/styling work. Your role is to make sure that the project as a whole is well designed and styled, and that the whole team works towards that goal.

QA

Responsibilities

• Monitor codecov and make sure test coverage is kept up

• Understand how to test pure functions, database queries, routes, DOM

• Understand how and when to use mocks

• Set up separate test database and destroy / build scripts

• Insist on clean and legible code

DevOps

Responsibilities

• Lead on setting up repo and file structure

• Make sure separation of concerns is considered

• Set up linting and check it works for everyone

• Set up deployment, e.g. to fly.io, and take ongoing responsibility

• set up environment variables for local and remote databases

Scrum Facilitator

Responsibilities

• Sprint planning

  • Prioritise issues

  • Break down larger issues into manageable chunks

• Lead standups and Sprint Planning

• Clear blockers

• Lead conversations with the Product Owner

• Listen to and mediate Product Owner needs

• Balance needs of the Product Owner with the needs of the Product Team

• Provide a daily rundown of work completed

• Lead Sprint Review

UX Lead

Responsibilities

• Advocate for the user

• Create a style guide

• Ensure design heuristics are followed

• Lead on user testing

• Lead on project documentation

  Note: The following are shared responsibilities that are not specific to the UX role. One person from the team should lead on ensuring project documentation gets done, but everyone should participate in writing it.

• Ensure regular attention is given to thorough documentation

• Provide support to the team in writing documentation

• Ensure completion of handover documentation for the Product Owner

During this training, apprentices will all be required to fill in a progress log. The template for this can be found in your cohort's GitHub organisation.

The purpose of the progress log is to enable apprentices to reflect on their learning week by week, identify strengths and areas for development, and to receive feedback on their progress from the Course Facilitators in order to improve.

This progress log must be updated every Friday as a reflection activity on the previous week's learning outcomes and ready for review by Monday morning.

No matter how well a team works together, or how well a week goes, there is always an opportunity to learn and improve.

We end every week with a retrospective. It is a dedicated period of time for students & mentors to deliberately reflect together on how we are doing and identify ways to improve.

Cohort retrospective

We have found the simplest & most effective format to run retrospectives is what is called a meeting.

The whole cohort of students sit in a circle, if space allows, with their mentors. Each student is given time to reflect on the week and identify specific things that we should:

• Stop doing

• Start doing

• Continue doing

The feedback can range broadly from environmental concerns, to timetabling, to feedback on workshops.

Once students have filled a whiteboard with their feedback, the facilitator will read each point and they are discussed by the group. The facilitator should not feel they need to respond to every issue and, except for reading out each point, doesn't talk more than the others.

An assigned notetaker will take rough minutes of the meeting as well as any action points. The minutes of these meetings are captured in the cohort organisation, forwarded to mentors of future weeks, and used when we review the curriculum. Each action point should be assigned to a particular person and at the beginning of the next SGC, the facilitator will check-in on progress with the assignees.

Team retrospectives

We also run a smaller "stop go continue" meeting with each project team so they are able to reflect on how their group project work went that week.

The team may want to assign somebody as facilitator. The facilitator should not feel they need to respond to every issue and, except for reading out each point, doesn't talk more than the others

We should always remember that no matter how difficult a project was, we do not default to blaming individuals. We work out as a group root causes behind problems, review the way we work together, and come up with actionable goals that will improve the next project for everyone.

Each week, you will be split into teams for weekly projects. These teams will be change throughout the course, giving you a chance to work with every other member of your cohort.

The Founders and Coders learning environment is all about collaboration, and this is a great opportunity to practise your workflow in a development team.

Project teams for each week are posted in your cohort repo, under the pairs-and-teams folder.

Remember to read each other's user manuals when you start working with a new team!

Please do not work on your projects outside of course time

This puts extra stress on everyone else. Remember that you are not expected to have a finished, polished project. It's about the learning journey, not the final outcome.

If you have the spare time and energy to code outside the course, focus on reviewing workshops or building side projects.

Project Setup

Utilize your project setup time to do the following:

• Name your GitHub repo in the format

  week#-<topic>-<team members' names or initials>

  for example:

  week2-database-reuben-gregor-oli-dan

• Decide on key user stories and finalise the end goal for the project

• Create a set of GitHub issue labels to make it easier to plan your sprints

• Split up the user stories into issues, and assign your first day's work.

• Create a GitHub project board. The simplest structure for this is three columns of to-do, in progress and done.

• • From week 2, decide who takes on each

Team workflow

• Pair program as much as possible - two brains are better than one, support each other!

• Decide how frequently you take breaks, and take them together!

• Don't always work on the same person's machine. Watching someone write code is very different to writing it yourself!

• Swap pairs every half-day. This means that you will break up work into more manageable chunks, but also that the team will work across different parts of the project, and with different people.

• Update your kanban board as you finish working on issues. Measuring your project velocity will be very beneficial during standups, so you can decide how to best use the remaining time in the sprint.

• Avoid focussing on a specific area too much (eg: if you're known as the CSS whiz, try not to find yourself single handedly fixing styling towards the end of the project). Challenge yourself, and pick tasks that make you uncomfortable!

A is a method for exploring potential solutions. They are usually used when a team needs to get familiar with a new technology, or does not know how to solve an important problem. The spike is a dedicated period of time to research a solution, which can then inform the project planning.

Every week your project will begin with a spike. There will be some aspect of the project that you need to research and plan as a group before starting to work on your app. There is dedicated time in the schedule for this.

During the first 6 weeks, spikes will include some example questions to kickstart your research. During the longer In-house and Tech for Better projects, project teams will decide their own Technical Spikes. Please include your findings in your project presentations at the end of the week—it's useful for each group to share their specific knowledge with the others.

Personal user manuals! Keep them updated, read them well 📒

How do I edit my user manual?

Go to the user-manuals repo in your cohort's github organisation. Click on the 'issues' tab above to create a new issue, by clicking 'New Issue'. Use the User Manual template as starting point, but remember that this is your space to reflect on yourself however fits you best. Try to fill in as much as you can now, so that updating it in the future is easier - and more rewarding.

Why are we doing this?

It's great to have a space to reflect on ourselves, and how we work in a team. Not only can this change over the course of 12 weeks of intense learning, but its also important to acknowledge that your work style in a development team might end up being different to how you've worked in educational/professional environments before. We can also learn about our team-mates before working together, so we know how to get the best out of each other and work well as a team 👭👬

It is also a wonderful idea to leave feedback as a comment on other people's user manuals, once you have worked with them.

Updating your user manual

Please update your user manual with any reflections on what you found out about yourself each week.

Example

You can see @jackherizsmith's user manual here: https://github.com/fac19/user-manuals/issues/10

Introduction

Tech for Better (TfB) is for social entrepreneurs, charities and early start-ups to learn about Product Management. We invite Product Owners (PO's) to work alongside developers on the apprenticeship training.

Tech for Better is broken into two programmes:

• Product Management Training

• Design, Test and Build

Product Management Training

You'll work with a cohort of Product Owners for the first 7 weeks of the apprenticeship training. Each week there will be one workshop where you'll complete exercises with Product Owners.

Design, Test and Build

After meeting and working with Product Owners, your cohort will select 3 ideas for the Design, Test and Build programme. This is the second of your two final projects. You'll work directly with a Product Owner to build a Minimum Viable Product (MVP). An MVP is an early stage version of a product with limited functionality. These can be used by Product Owners to test their idea with users, or as a proof of concept which can be shown to funders and investors.

Schedule

Week 1 - Introduction

In the first week of the programme, we'll introduce the Tech for Better programme. This will give you an overview of what you'll do each week in preparation for building an MVP with a real client.

Week 2 - Product Pitches

Meet the cohort of Product Owners in quick, rotating conversations. By the end of the session all developers will have an initial understanding of who each PO's user group is, the problem that the user group is facing, and how a digital product will benefit those users.

Week 3 & 4 - Discovery Workshops

The Discovery Workshop is repeated, with half the Product Owners attending each week. This means you'll work with two different Product Owners to explore their ideas in more depth.

For each product, the PO and a group of developers define a Problem Statement. You'll create user personas and write questions to form the basis of user interviews which Product Owners will conduct in week 5.

Week 5 - User Research

Product Owners conduct user interviews independently with their user group.

We take this week to discuss project ideas as a cohort for the In-House Project.

Week 6 - Research Analysis

Team up with one or two Product Owners to analyse the user research they've conducted.

Week 7 - Product Management

This session is a practice in scoping a product idea and breaking it down into user stories. You'll analyse a few mock product ideas, break one of them down into user stories, and then plan a sprint.

Week 8 - Selection

Review all product ideas as a cohort (without Product Owners present) and submit your preference of products to continue working on.

Week 9 - Analysis Workshop

Following your selection, you'll work with a chosen Product Owner to map out the product idea.

Together you'll plan the main path through their application and then come up with a set of user stories which describe the functionality of the product.

Week 10 - Design Week

During the first half of TfB Design Week, you'll work alongside your Product Owner to scope and wireframe a prototype. Starting with a Definition Workshop, you'll come up with ideas and sketches of what the product might look like. After you've decided on a direction with your PO, you'll have some time to create a wireframe in Figma.

With this wireframe, you'll conduct testing with users who have been coordinated by your Product Owner. Feedback from users will be analysed by your team and PO.

You'll now be ready to analyse the idea and start to plan out your tech stack. In the final part of the week you'll plan for your build time and have some time to do Tech Spikes focused on the technologies you'll be using.

Week 11 & Week 12 - Build Sprints

Build your MVP across two build sprints, with support and guidance from your Product Owner. At the end of Build Week 2, you'll present your MVP at the Tech for Better Showcase.

We have an Employee Assistance Programme for FAC learners.

What this means is that all learners have access to up to 6 free therapy sessions, face to face, online or via video call per year and this is available 24/7, 365 days a year. There is also a health and wellbeing app and other forms of support available including:

• Family advice line

• Finance and debt information

• Legal advice

For more information on how to access the service, click here.

To read through some FAQs about the offer click here.

Should you want to access more longer-term talking therapy, this document outlines affordable options in the local area and across London.

Pastoral Walks

Pastoral walks are designed to help you navigate through your learning journey with us. These are casual, one-on-one conversations with our course facilitators, where you can talk about your progress, any challenges you're facing, and give feedback to your CF.

What Happens During Pastoral Walks?

During these walks, your CF will:

• Listen to Your Concerns: Whether it's about your coursework, career goals, or personal challenges, they're here to help.

• Offer Guidance: They can provide advice on handling academic or professional challenges and help you navigate interpersonal issues.

• Answer Your Questions: Whether it's about the full-time program, employment preparation, or project expectations, they're a valuable resource.

• Avoid Direct Involvement in Conflicts: They'll help you approach and resolve conflicts, but won't get directly involved.

Pastoral Walk Aims

Foundation programme

• Discuss employment expectations

• Discuss any interpersonal challenges that have come up

• Identify future plans

• Ask questions about curriculum work (the structure and not the code)

Apprenticeship

• Discuss any interpersonal challenges that have come up

• Ask questions about the full-time programme

• Discuss support with preparing for employment

• Discuss upcoming projects

Recording Your Progress

After each pastoral walk, your CF will note down:

• Any concerns that you've shared during the programme

• Any agreed actions: Any advice or steps suggested, including follow-ups.

Web development does not require a particularly powerful computer—you'll mostly be editing text files and using a web browser.

That said there are some minimum requirements you'll need to meet to get the most out of the course.

Summary

• We recommend using a Mac laptop or a Windows laptop with a Linux environment

• We recommend a minimum of 5GB of free space on your laptop

• We recommend your laptop has a minimum of 4GB of RAM

More detail

Operating system

The most important thing is having a consistent terminal environment. macOS and Linux are both based on Unix and so have a standardised command-line environment. This is useful because most things will work cross-platform . Also pretty much all cloud platforms use Linux, so the places you are deploying code will work the same way.

Windows has a totally different command-line. The underlying OS is different enough that you will encounter issues even with very popular tools.

This is changing with Windows Subsystem for Linux, which lets you run a Linux system within Windows. It's still very new but looks promising for standardised development on Windows.

We'd recommend Windows users try running Ubuntu within WSL2. If that doesn't work then try dual-booting a full copy of Ubuntu alongside Windows.

We recommend using a Mac laptop or a Windows laptop with a Linux environment.

Storage

Modern JavaScript apps rely on lots of 3rd-party modules that get installed into your project. This means that although you might only have a few of your own files, you could well have hundreds of megabytes in your node_modules folder per project.

The React Week workshops and project alone can take up almost 1GB of space.

We recommend a minimum of 5GB of free space on your laptop. You can probably work with less than this but you'll have to be diligent about deleting older projects.

RAM

You're going to be spending a lot of time in a web browser, usually with many tabs open. Modern browsers can be pretty memory-hungry (looking at you Chrome), so having more RAM tends to make for a smoother experience. If your laptop runs out of RAM it'll start suspending apps/tabs in the background, which isn't ideal.

We recommend your laptop has a minimum of 4GB of RAM. You can't really have too much here though, 8GB would probably be ideal.

This policy describes our approach to safeguarding and promoting the welfare of vulnerable adults. It applies to all of our work with learners (both apprentices and not), and includes our permanent core team and any part-time or volunteer contributors.

Reporting concerns

We strive for our learners to both be and feel safe. If you have a Safeguarding or Prevent concern regarding yourself, another learner or a member of the FAC team, please speak with Anna, who is our Designated Safeguarding Lead.

If you have a concern involving Anna, please speak to Dan: dan@foundersandcoders.com If you have a concern involving Dan, please speak with our board member, Anni: anni@intersticia.org

Our core team understand safeguarding indicators and will respond proactively to any concerns that are raised.

You can also raise concerns using our Safeguarding Concerns Form: Safeguarding Concerns form.

What safeguarding is

Safeguarding is protecting children, young people and adults at risk from abuse and neglect. It means protecting the physical and mental health of children, young people and adults at risk. Effective safeguarding should allow children, young people and adults at risk to get the best outcomes in life.

Founders and Coders is for adult learners, so the rest of this policy is focused on safeguarding adults specifically.

Safeguarding vulnerable adults is defined in the Care and support statutory guidance issued under the Care Act 2014 as:

• protecting the rights of adults to live in safety, free from abuse and neglect people and organisations working together to prevent and stop both the risks and experience of abuse or neglect

• people and organisations making sure that the adult’s wellbeing is promoted including, where appropriate, taking fully into account their views, wishes, feelings and beliefs in deciding on any action

• recognising that adults sometimes have complex interpersonal relationships and may be ambivalent, unclear or unrealistic about their personal circumstances and therefore potential risks to their safety or well-being

Why safeguarding is important

Having a robust safeguarding policy is important to ensure we do not miss signs of abuse or neglect. We want our programmes to be a safe place for people to learn, and this cannot happen unless everyone involved is vigilant in following safeguarding procedures.

Safeguarding concerns

• neglect

• physical abuse

• sexual abuse

• emotional abuse

• bullying, including online bullying and prejudice-based bullying

• racist, disability and homophobic or transphobic abuse

• gender-based violence/violence against women and girls

• honour-based violence

• domestic abuse

• sexual harassment and online sexual abuse between learners. Online abuse can include sending abusive, harassing and misogynistic messages; sharing nude and semi-nude images and videos; and coercing others to make and share sexual imagery

• upskirting

• radicalisation and/or extremist behaviour

• substance misuse

• female genital mutilation

• forced marriage

• homelessness

Prevent duty

As an apprentice training provider we have a duty to prevent our learners from becoming radicalised by extremist ideologies, or drawn into terrorist activity. The Government defines extremism as "vocal or active opposition to fundamental British values, including democracy, the rule of law, individual liberty and mutual respect and tolerance of different faiths and belief".

This is important as extremism is an ongoing threat to the UK. Anything we can do as an organisation to help prevent radicalisation can contribute to reducing this danger.

2023 Categories of extremism

• Extreme right wing

• Islamist

• Mixed, unstable and unclear(MUU) subcategories include:

  • Incel

Extremist influences could include, but are not limited to:

• family members having direct contact or involvement with extremist or terrorist groups

• staff members of an education or community setting promoting an extremist ideology

• peers promoting an extremist ideology or sharing extremist material

• access or exposure to online extremist material via social media or the internet - for example, propaganda including pictures, videos, blogs and fake news

• exposure to extremist, terrorist or other violent activity in overseas settings

• access or exposure to extremist leaflets, magazines or stickering

• exposure to extremist groups hosting marches, protests or stalls

Push Factors

Push factors may include a child, young person or adult learner feeling:

• isolated

• they do not belong

• they have no purpose

• low self-esteem

• their aspirations are unmet

• anger or frustration

• a sense of injustice

• confused about life or the world

• real or perceived personal grievances

Pull Factors

Pull factors could include an extremist or terrorist group, organisation or individual:

• offering a sense of community and a support network

• promising fulfilment or excitement

• making the child, young person or adult learner feel special and part of a wider mission

• offering a very narrow, manipulated version of an identity that often supports stereotypical gender norms

• offering inaccurate answers or falsehoods to grievances

• encouraging conspiracy theories

• promoting an ‘us vs. them’ mentality

• blaming specific communities for grievances

• encouraging the use of hatred and violent actions to get justice

• encouraging ideas of supremacy

Towards the end of your cohort, you'll have the opportunity to reflect with the rest of your cohort on the mentoring you've received. The goal of this reflection is to come up with ideas for what you'd like to take forward to mentoring the next cohort.

The exercise

You'll have 75 minutes to reflect and share your thoughts together.

Spend the first 10 minutes thinking individually and writing a list of things you found were good qualities, or behaviours which you saw from your mentors.

You'll then split into small groups to come up with a shared list, building on your individual reflections.

After 15 minutes in your small groups, we'll come back as a cohort. Each group will take turns to share each reflection from their list.

Someone in the cohort can be nominated to take notes and add the document somewhere for you all to refer back to.

At the end of the session, we'll ask you to fill in an airtable form with your preferences on which week you'd like to mentor for the next cohort.

When you're mentoring the next cohort, you can refer back to your reflections to guide your mentoring.

The presentations for Tech for Better are a little different from the other ones you've delivered during the programme. We'll host a showcase of projects on the last day of term. We invite alumni, and other friends and family along to watch the presentations.

You will present for a maximum of 15 minutes, alongside your Product Owner.

Audience

Your audience won't all be technical experts, and you'll want to include the right level of detail for everyone. Talk about some of the challenges of building the product, and try to keep these high-level.

You may get some questions from the audience, who'd like to learn more about what you've been working on. If there's a question you'd like to be asked, you can ask another member of your cohort to ask it 😉

Introductions

Introduce yourselves and your Product Owner to the audience. Include your project role in your introduction.

It can be a nice touch to take turns introducing another member of the team; and paying them a compliment on their work.

The Problem

Detail what problem the Product Owner wanted to solve. You might like to ask your Product Owner to talk through this slide, and include a Problem Statement.

Design

Talk about how you planned and designed the Product with your PO. Include screenshots of your design process.

Tech Stack

Give details on the stack you chose, and why you chose each technology.

Product Demo

Talk through the main features of the product, and show the user journey. We encourage you to pre-record a demo, and include a video in your slide deck. This can help to avoid any unexpected issues on the day, and can help keep the demo well-timed.

Challenges

Talk about some of the challenges you faced during the build. This might be related specifically to your role, and you might like to follow this structure:

• What the challenge was

• How you solved it

• The benefit of solving that challenge

What you're proud of

Let the audience know about your big achievements in this build. What did you do that you were proud of?

What you learnt

What did you learn during the project? Give your PO time to talk about what they learnt throughout the programme too.

What's next?

Give your Product Owner time to talk about the direction of the product and where they'll take it next. They might be looking for further funding or development, or testing the MVP with their user group.

Timing and structure

Share the speaking time evenly throughout your team. Each person, including the Product Owner, should aim to speak for 2 - 2.5 minutes.

The structure here is an outline, and you can adapt it to make the presentation your own.

During sprint planning, you'll estimate all of the issues in your backlog. Once everything has been estimated, you'll be ready to plan what you'll work on in the next sprint.

Before the sprint begins, set up a project board with all of the user stories you'll work on. You'll be able to refer to this to track your progress throughout the sprint.

During the , your Product Owner will join your planning sessions. The Product Team should lead the process and give the Product Owner a clear idea of what you'll be working on in the next sprint.

Sprint Review

In a sprint review, the Scrum Facilitator will lead the team in working out the actual complexity of each issue tackled. Add actuals as labels to the issues you completed within the sprint and use these to calculate your velocity for the sprint.

After completing a review of your first sprint, you'll be able to better manage your next sprint backlog with your velocity in mind.

At the end of your Tech for Better project, you'll hand the project over to your Product Owner. For a smooth transition, you'll write documentation to help them continue to manage the product.

Product demo

Start by showing them around the application and what features you've built. It's important that they understand how it works, and that you will no longer be able to contribute to the repository.

If you do find bugs, don't aim to fix them in the handover. Open issues which give details of the bugs, and how they might be fixed. This will allow your PO to pick up development further down the line.

GitHub

Share the repository with your PO. You can add them, if they want to make a profile, or just share the link. Make sure you have a clear README with details of the stack, and how the project fits together.

Show them the Product Backlog and let them know what is still to be included. They'll manage this backlog if they continue to develop the product.

Logins

Pass any logins to your Product Owner and make sure they can manage the deployment, and any CMS you've built moving forward. Do not share your personal login to the platform, encourage them to create their own and transfer ownership.

Further Development

If your Product Owner mentions continuing work on the Product, you can direct them to chat to the team at Founders and Coders. We can support them with finding developers to work on the project. You may also like to show them how to create issues on GitHub, if they are planning further features to develop.

There are two kinds of user feedback sessions in the design sprint: User Research, and Usability Testing.

User Research

User research gives us an opportunity to validate whether we’re on the right track, or if we’re designing something that wouldn’t address user needs.

• When conducting user research it’s important to keep an open mind and to be unafraid of readdressing our approach.

• Critical feedback is incredibly useful to us so we want to encourage our users to be open and honest.

• You'll be asking the participant questions from a script prepared ahead of time, and taking notes of their answers.

• It is important that you help the user feel comfortable and ask open questions as well as giving the user space to share their own thoughts.

• Users might not have participated in research before so there often is a tendency to tell us what we’re expecting to hear. But critical feedback is incredibly useful to us so we want to encourage our users to be open and honest.

• Wherever possible, we want to avoid including our own biases in questions and conversations as part of user research.

• Always be mindful of the participants right to privacy.

• Once the interviews are all conducted you will synthesise the feedback in your project groups during the Analysis workshop.

Usability Testing

Usability testing is a process for getting feedback from real people in order to inform the decisions we make on designing and building a digital product.

• 'User Testing' and 'Usability Testing' refer to the same thing. The phrase ‘usability’ encourages us to remember it is not the user who we’re testing but the usability of our app or product. Do take the opportunity to rethink your app, and take all criticism constructively!

• You will be conducting an interview where you will ask the user to navigate through your Figma prototype.

• Keep your explanation brief. Introduce them to the project idea in one or two sentences and explain how usability testing works.

• Giving them a few tasks to complete and observing how they interact with the prototype will give you an idea of how intuitive it is to interact with the product you're creating.

• Feedback from testing will help inform your decisions on which features to prioritise when building.

Process

During the In-House project design sprint (week 7) you will be conducting both user research and usability testing.

The Tech for Better Product Owners will conduct their own user research, but you will be conducting a usability testing session with their user group.

• Check the design week schedules for exact timings:

  In-House Project Schedule

  Tech for Better Project Schedule

For the In-House project, you will need 1-2 volunteers per person to participate:

• User research (1-2 volunteers each, 6 per team)

• Usability testing (1-2 volunteers each, 6 per team)

• Each research session will last 90 minutes, whereby each interview will take around 20-30 minutes to conduct.

• They will be 2-1 interviews over zoom (2 developers interview one participant) , or face to face wherever possible.

• You will conduct the research in pairs, where one person will be taking the lead and asking questions, whereas the other person will be taking notes on the volunteers answers.

• Please swap roles between interviews so that everyone gets a chance to ask questions.