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

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?

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

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

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.

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 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:

will produce something like this:

If your project is on GitHub then consider linking directly to the lines of code in question. You can do this by . 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.

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

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 .

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?!

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 , an error message, then a stack trace. Let's look at an example error and break it down:

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 and give 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 .

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

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

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

UX Lead Guidance:

• Advocate for the user

  • Show us your prototype

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

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.

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

Before you start you should read the System Requirements 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 troubleshooting section.

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

Git

is a program for tracking changes to the code you write. Most systems come with this installed, but it's worth making sure you have a relatively recent version. You can run this in your terminal to check the version:

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

Mac

Linux

Configuring Git

You will need to tell Git your and . It uses these to record who wrote each bit of code in a project.

You should make sure the email matches your email on GitHub, so that you don't end up with multiple versions of yourself committing to a project. If you want to keep your email private with a "no-reply" email for use with Git.

We'd recommend going through GitHub's , and guides as there are some extra bits of setup you probably want to do.

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

We'll install Node with , which is a tool for managing Node versions. This command will download their install script (with curl) then pass the script to bash to run it:

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

You probably want to install a nicer Terminal program than the default. This is mostly down to personal preference, but you'll be spending a lot of time in the Terminal so it's worth finding something you like. We also recommend .

Mac

is great on macOS. You can either install it manually from their website or with Homebrew:

Windows

The new Windows Terminal is designed for Linux-on-Windows (WSL). They recommend you install it from .

Code editor

You'll be writing a lot of code, so you'll want a nice editor. We recommend . It's probably easiest to install this via the website.

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

As a web dev most of the software you write will run in a web browser. You'll need any modern browser—ideally , or (Safari doesn't have the best developer tools).

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

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.

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.

• 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

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

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

• of terms.

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 (prettier) 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.

• , 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.

The employment curriculum

In pairs from previous project teams

• Week 4 GitHub

• Reading week Employment mentor intro

In React pairs

With TfB team

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

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.

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.

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.

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.

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;

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;

Tools

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

• of terms.

A guide to leading and supporting peer learning using our coursebook

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#

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.

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

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

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 .

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

Reading a function

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

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

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.

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.

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.

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

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.

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

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

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.

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.

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:

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

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.

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 Tech for Better projects, 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.

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.

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.

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.

We recommend using for your slide deck ✨

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 .

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.

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:

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.