1 of 100

coursebook

FAC Curriculum

This repo contains the source code and content for our open-source curriculum: learn.foundersandcoders.com.

Running locally

Clone this repo
Run npm install to install all the required dependencies
Run npm run dev to start an auto-reloading development server

Alternatively run npm run build to create the final production _site directory. You can serve this with any web server as it's static HTML, CSS and JS.

Git hooks

This package installs a custom pre-commit Git hook when you npm install. This hook automatically formats your changes using Prettier (with the default settings). This ensures all files have consistent style and formatting. So don't be surprised if you see things move around a bit after you commit a change.

Node & npm introduction

Learn how to use Node and npm to run JS on your machine

Node is a version of JavaScript that works outside of a web browser. It was created so web developers who already knew JS could use the same language to write HTTP servers, CLI programs and more.

Node JS vs Browser JS

Node is basically the JS engine from the Chrome web browser, plus some extra features for things browsers cannot do, like making HTTP servers or accessing files on the computer.

Since Node uses the JS language it has the same syntax, keywords and features as JS in the browser. However (just like browsers) different versions of Node support different new language features. Something that was added to JS in Chrome may not be available in Node yet (and vice versa).

The main difference to browser-JS is that Node has no window or document global objects (and so none of the things inside them like querySelector), since those concepts only make sense in a browser.

Installation

You'll need to have Node installed on your computer to follow this workshop. Check whether it is already installed by running this in your Terminal:

node --version

Our programme relies on some features that were only added in Node version 18 (the current version), so if you have an older version than that you should install the newer one with:

volta install node@18

Using Node

The Node installation on your computer comes with a command-line program called node. This allows you to use the node command in your Terminal to run JS code.

REPL

The quickest way to try Node out is with the "REPL". This stands for "read, eval, print, loop" and is a quick playground for running code (most languages come with one).

Run this command in your Terminal to start the REPL:

node

You should see something like:

Welcome to Node.js v18.5.0.
Type ".help" for more information.
>

You can type JS code in here, then hit "Enter" to execute it (just like a browser console).

JS files

The REPL is mostly for playing around. To write a real program you need .js files. You can tell Node to run a JS file by passing its path as an argument:

node my-file.js

Node will parse the JS code in the file, execute it, and display anything logged in your terminal.

Node package manager

Node comes with a "package manager" called npm. This is a way to easily install and use code written by other people. This is generally more robust than just copy/pasting code from the internet.

The npm company maintain a registry that anyone can upload code to, containing thousands of 3rd party modules. They also have a command-line program for managing those modules in your project. This comes with Node, so you should already have this CLI available:

npm --version

`package.json` file

Node projects usually have a configuration file called package.json. This is a special file that lists information about the project, including any dependencies. These are modules installed from npm that your project uses.

`npm init`

This command will "initialise" your project by asking you some questions then creating the package.json.

You can pass the -y flag to skip all the questions and create the package.json with the defaults. You can edit the JSON file by hand later if you need to.

`npm install`

This is how you install 3rd party modules to use in your code. For example to install the very useless cowsay module:

npm install cowsay

npm will list the module in the "dependencies" field in your package.json:

{
  "dependencies": {
    "cowsay": "^4.1.2"
  }
}

Now when another developer needs to work on your project they can clone your repo then run just this command:

npm install

npm will read the dependencies listed in the package.json and automatically download all the 3rd party modules required to run the project.

npm will also create a directory named node_modules and put all the 3rd party code in there. This will be quite large, since modules you install can have their own dependencies (and those dependencies can depend on other modules...). Since this directory gets so big it's common to add it to the .gitignore file.

Development dependencies

Some 3rd party modules are only used for development purposes. E.g. a testing library or a linter. You can mark a module as a dev dependency with the -D flag when you install:

npm install -D cowsay

This will put it under the "devDependencies" field in the package.json. This helps during deployment—it's quicker not to install a bunch of modules that aren't actually needed for your production server.

Global modules

You can also install modules "globally" on your computer using the -g flag. This makes them available to use anywhere in your terminal, and so is sometimes used as an alternative to Homebrew or apt-get.

You shouldn't use global modules in your Node apps, since they aren't listed in the package.json and so won't be installed automatically if another developer clones your repo and runs npm install.

npm scripts

It's common for modules you install to have command-line programs you can run in your terminal. E.g. the popular ESLint linter installs a CLI so you can check your code by running a command like eslint add.js.

npm installs dependency CLIs into node_modules/.bin/. This means you can run the cowsay CLI we just installed in our terminal like this:

node_modules/.bin/cowsay hello

However this is pretty awkward to type, especially if it's a command we need to use a lot (like "start the dev server"). Luckily npm scripts make this nicer.

npm automatically creates a field called "scripts" in your package.json. These are shortcuts for different tasks you might want to do while developing your app. They're like per-project command-line aliases.

npm will automatically add ./node_modules/.bin to the path of any command you use in these scripts. So you could add a "greet" script like so:

{
  "scripts": {
    "greet": "cowsay hello"
  }
}

You can run npm scripts in your terminal with npm run <name>. So in this case:

npm run greet

developer

Programming Paradigms

A programming paradigm is a way of thinking and structuring code that provides guidelines and patterns for solving problems. It encompasses a set of principles and techniques that determine how software is designed, organized, and executed.

The different programming Paradigms

Imperative
Procedural
Object-Oriented
Declarative
Functional
Logical
Reactive
Event-driven
Concurrent
Parallel
Domain-Specific

This is not an exhaustive list of all the paradigms that exist, however they are some of the more popular ones.

We will be focusing on the following 3:

Imperative
Declarative
Reactive

Imperative Programming

Imperative programming is a programming paradigm where programs consist of a sequence of instructions that explicitly state how to achieve a desired outcome. It focuses on changing the program's state through direct manipulation of variables and control flow structures.

Real-world Example

Let's say you have a recipe for making a sandwich. In an imperative programming paradigm, you would follow a sequence of steps explicitly stated in the recipe to achieve the desired outcome of making the sandwich.

Gathering the necessary ingredients (bread, lettuce, tomatoes and mayonnaise)
Spread mayonnaise on the bread
Add the lettuce and tomatoes
Assemble the sandwich.

In this example, the recipe serves as the sequence of instructions, and you are following those instructions step by step to achieve the specific outcome of making the sandwich. Each action changes the state of the sandwich (adding ingredients, spreading condiments) until the desired state (a complete sandwich) is reached. This illustrates the imperative programming paradigm's characteristic of explicitly stating and executing a sequence of instructions to accomplish a specific task.

Coding Example

Let's look at a simple coding example that calculates the factorial of a number

function factorial(n) {
  let result = 1;

  for (let i = 1; i <= n; i++) {
    result *= i;
  }

  return result;
}

const number = 5;
const factorialResult = factorial(number);
console.log(`The factorial of ${number} is ${factorialResult}`);

In this example, the factorial() function calculates the factorial of a given number using an iterative approach. It initializes a result variable to 1 and then uses a for loop to multiply result by each number from 1 to n.

The code follows a sequence of steps explicitly defined in the function, executing each instruction in order to achieve the desired outcome of calculating the factorial. It represents the imperative programming paradigm by explicitly stating how to accomplish the task and manipulating the program state (the result variable) to achieve the desired result.

Declarative Programming

Declarative programming is a programming paradigm where programs specify the desired outcome or goal without explicitly stating the control flow or steps to achieve it. It focuses on describing what should be done rather than how to do it.

Real-world Example

Consider a shopping list. Instead of specifying the exact steps to go to the store, navigate through aisles, pick up items, and pay at the counter, a declarative approach would be to simply list the items needed and let someone else handle the implementation details.

Milk
Eggs
Bread
Orange Juice

Coding Example

Let's look at a simple coding example that filters even numbers from an array

const numbers = [1, 2, 3, 4, 5, 6];

const evenNumbers = numbers.filter((num) => num % 2 === 0);

console.log(evenNumbers);

In this example, the filter() method is used to declaratively specify the desired outcome of extracting even numbers from the numbers array. By providing a callback function that checks if a number is even (num % 2 === 0), the filter() method takes care of iterating over the array, executing the logic, and returning a new array with the filtered results.

The code expresses the desired outcome (filtering even numbers) without explicitly stating how to perform the iteration or filtering. The declarative programming paradigm allows us to focus on the "what" (filtering) rather than the "how" (iteration and condition), letting the underlying implementation handle the details.

Declarative vs Imperative Programming

** Imperative **

function Box() {
  const div = document.createElement("div");
  div.classList.add("box");
  div.append("Hello world");
  return div;
}

Here you're giving the function specific instructions to create a div with the class "box" and contain a "Hello World" message.

** Declarative **

function Box() {
  return <div className="box">Hello world</div>;
}

Whereas, with declarative programming you define the div element's className as "box" yourself, without giving instructions on how that div should be created.

The Pro and Cons of Declarative Programming

Pros:

Simplicity: Declarative programming simplifies code by focusing on the desired outcome rather than the detailed steps, making it easier to read, understand, and reason about.
Abstraction: Declarative code promotes abstraction and encapsulation, allowing for reusable and modular components that can be composed to solve complex problems.

Cons:

Learning Curve: Declarative programming may require a shift in thinking and understanding higher-level abstractions, which can initially be challenging for developers more familiar with imperative paradigms.
Limited Control: Declarative code abstracts away control flow and implementation details, which can be limiting in certain scenarios where fine-grained control or performance optimizations are required.

The Pro and Cons of Imperative Programming

Pros:

Control: Imperative programming provides fine-grained control over the execution flow, allowing developers to explicitly define the sequence of steps to achieve a desired outcome.
Flexibility: Imperative code can be more flexible and adaptable, as it allows for direct manipulation of program state and detailed control over low-level operations.

Cons:

Complexity: Imperative code can become complex and harder to reason about as programs grow in size and complexity. The explicit control flow and mutable state can lead to code that is harder to understand and maintain.
Code Reusability: Imperative code often tightly couples the logic with the specific implementation, making it less reusable in different contexts or for different tasks.

Reactive programming

Reactive programming is a way of writing code that focuses on how data changes and flows over time. It allows developers to easily define and handle data streams in a way that is responsive and event-driven.

How does it work?

Here are two example of some code that take a name as a parameter and will output a h1 message "Hello, {name}".

import React from "react";

// JSX component
const Greeting = ({ name }) => <h1>Hello, {name}!</h1>;

// Usage in JSX
const App = () => <Greeting name="John" />;

In the above example, we utilize JSX syntax, which is commonly associated with React. JSX allows us to write HTML-like code within JavaScript, making it easier to define and render components. The Greeting component is defined as a function that receives a name prop and returns an HTML element. The App component renders the Greeting component with the name prop set to "John".

// Vanilla JavaScript equivalent
const Greeting = ({ name }) => {
  const element = document.createElement("h1");
  element.textContent = `Hello, ${name}!`;
  return element;
};

// Usage in vanilla JavaScript
const App = () => {
  const greetingElement = Greeting({ name: "John" });
  document.body.appendChild(greetingElement);
};

The above code example is written using vanilla JavaScript but achieves the same result as the JSX example. The Greeting component is defined as a function that creates a new HTML element, sets its text content, and returns it. The App component creates an instance of the Greeting component, appends the returned HTML element to the document body.

Comparatively, the JSX approach provides a more intuitive and concise syntax, resembling HTML, and simplifies the process of creating components.

In vanilla JavaScript, the equivalent code requires manual element creation, manipulation, and appending to the DOM.

JSX, with the help of a tool like Babel, transpiles the code into plain JavaScript, but it enhances the readability and maintainability of the code for developers working with React or JSX-based frameworks.

DevOps

Amazon CloudWatch is a monitoring tool used to collect and visualise real-time logs, metrics, and event data in automated dashboards.

handbook

Asking for help

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!

Try to debug on your own
Google the problem
Describe the problem and what you've tried
Make sure to include a code sample
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.

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>

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.

Coaching groups

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:

A forum for group members to get support on a problem they have been working on; or
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:

A problem that they want help with; or
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:

Support the Proposer to find a solution to their challenge; or
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

Code review

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

Course rules

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

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

Debugging

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

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

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.

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

Employment schedule and material delivered in FAC20

In pairs from previous project teams

Week 4 GitHub
Reading week Employment mentor intro

In React pairs

With TfB team

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

GitHub Workflow

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:

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>"
When you finish working on your branch, make sure it's up-to-date with main before pushing

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.

Glossary or terms

Presentation Guidance

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:

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

Equality, Diversity and Inclusion

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.

Installation guide

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

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

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

git --version

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

Mac

brew install git

Linux

apt-get install git

Configuring Git

git config --global user.name "Example Name"
git config --global user.email "email@example.com"

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

curl https://get.volta.sh | bash

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 install node@18

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

node --version

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:

volta install npm

Terminal

Mac

brew install --cask iterm2

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:

sh -c "$(curl -s https://learn.foundersandcoders.com/installation-checker.sh)"

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

Read the error message. If it's very long make sure you scroll right to the top.
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.
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.
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:

echo $SHELL

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:

ls -a ~

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

code ~/.zshrc
# or
code ~/.bashrc
# or
code ~/.bash_profile

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

export VOLTA_HOME="$HOME/.volta"
export PATH="$VOLTA_HOME/bin:$PATH"

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:

==> Tapping homebrew/core
...
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Failed during git fetch...

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.

Learning circles

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:

To give each participant an opportunity to get the support of the group with a problem that they are working on;
To give each participant practice in developing questioning strategies to aid problem solving;
To give each participant practice at communicating proposed solutions;
To give each participant practice at thinking reflectively about their learning processes;
To ensure that each participant gets an equal opportunity to develop their problem-solving skills;
To develop the capacity of all participants to run a strucutured study group without a facilitator present.

Tools

Mentoring guidance

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:

Ensure Ownership: Make sure you are an owner of the cohort's GitHub organization.
Familiarize Yourself: Read the workshops, solutions, project details, and learning objectives for your week. Note any changes made since your cohort started.
Communicate with the Course Facilitator: Check in with the course facilitator for support before, during, and after your week.

During Your Week:

Delegate Responsibilities: Decide who will lead specific portions of your week. Refer to the day-by-day checklist for a detailed breakdown.
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:

Understand Cohort Expectations: Read the cohort expectations document located at GitHub > fac# > cohort > expectations.md.
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:

Share Experiences Mindfully: Avoid creating unnecessary expectations based on your own experience. Frame your experiences as such and only share when directly asked.
Avoid Negative Opinions: Refrain from dismissing or criticizing course material. Present the curriculum and allow learners to form their own conclusions.
Empower Through Questions: When approached with a problem, ask questions to guide learners in finding the answer themselves.
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.
Encourage Collaboration: Suggest seeking input from team members or other teams who have encountered similar problems.
Visualize Solutions: Keep a notepad and pen ready to visually aid explanations by drawing out problems and solutions.
Embrace Not Knowing: If you don't know the answer, admit it honestly and collaborate with learners to find the answer together.
Break Down Big Problems: Help learners tackle overwhelming tasks by breaking them down into smaller, manageable steps.
Allow Room for Mistakes: Let learners stumble and learn from mistakes. Provide support and encouragement during their problem-solving journey.
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.
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

What to expect from your mentors

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

Cohort alumni who recently completed the course.
Join workshop discussions and provide support during projects.
Offer guidance without giving direct answers.
Share experiences, debugging advice, and tips for maximizing the course.

Project mentors

Support during final project(s).
Can be FAC alumni or apprenticeship employers.
Provide technical advice on tech stack choices and recommended libraries.
Not available for day-to-day debugging; use available resources like StackOverflow, cohort members, and the FAC community.
Schedule specific slots to discuss project-related matters.
Responsible for reaching out, scheduling time, and clearly communicating support needs.

One-day projects

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

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.

Portfolio

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:

KSB

Definition

Evidence

All stages of the software development life-cycle (what each stage contains, including the inputs and outputs)

Update contact form - Page 2

The roles and responsibilities of the project life-cycle within your organisation, and your role

New login modal - Page 4

How best to communicate using the different communication methods and how to adapt appropriately to different audiences

Update contact form - Page 10

...

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.

Questions for problem solving

Reading a function

Where are the inputs (or arguments or parameters) to the function?
Can you see any clue as to what type of value the function takes as arguments?
Where is the output (or return value) of the function?
Can you see any clue as to what type of value is being returned?
If a variable is returned, where is it first defined?
If a variable is returned, where is it updated after it is first defined?
Where are the function arguments used inside the body of the function and how are they used?
What other variables are declared inside the function; where and how are they used?
Can you see any other clues as to what the function is doing?
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?
Can you think of a real-worl use for this function?

Writing a function

Can you put into your own words, what this function is supposed to be doing?
If a function outline is provided, can you describe what each part of the outline is doing;
What is a sensible name for this function?
What type of value does this function return?
What arguments does this function need to produce a meaningful output?
Have the arguments got sensible names?
What methods could you apply to the arguments to get the required output?
How could you break this problem down into smaller parts?
If tests are provided, what happens when you run the tests and can you explain what each of the test results mean?
If tests are provided, could you amend the return value to pass the first test?
And subsequent tests?
If you are getting error messages when running the code, what are the eror messages telling you?

Progress Logs

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.

Final project report

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)

Managing software projects

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

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.

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.

Project Presentations

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

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?
Briefly demo your project and explain how it conforms to your brief i.e. the user stories and acceptance criteria
Show your project board and (from Week 2) report on estimated vs actual velocity
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
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.
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

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!

Project roles

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

Projects

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.

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!

Retrospectives

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

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.

Role Circles

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.

Safeguarding policy

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.

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

Technical Spikes

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.

System requirements

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

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

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.

Tech for Better

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

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.

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.

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.

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

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.

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

User Manuals

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

Wellbeing Support

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

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.

project-docs

What makes a mentor?

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.

Product Handover

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.

Sprint Planning

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.

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.

Tech for Better Presentations

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.

User Research & Usability Testing

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.

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:

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.

foundation

full-stack

Learning Outcomes

You should be focusing on meeting these learning outcomes over the three-week period. You will be tested on your learning during weekly quizzes.

project

testing

project

Your project this week is to build a to-do list tracker. It should allow users to create, complete and delete tasks from a list.

You should have automated tests covering all the main user stories. Each story below has a test "shell". You have to fill out the body to create a failing test for each story. You should then see the tests pass as you add features to your app. This is the minimum amount of testing required: you should write additional tests to cover the rest of your code.

User stories

Core

As a busy person, I want to:

Add tasks to a list so that I can keep track of them

test("Submitting a new task adds it to the list", () => {
  // test goes here
});

Check things off my list so that I can see what I’ve done

test("Checking an entry marks it as complete", () => {
  // test goes here
});

Delete things from the list if I don’t need to do them anymore

test("Deleting an entry removes it from the list", () => {
  // test goes here
});

As a motor-impaired user, I want to:

Use all the features of the app without a mouse

Stretch

As a busy person, I want to:

Filter out completed to-dos from my list so that I can focus on what's left to do

test("Toggling the filter hides completed tasks from the list", () => {
  // test goes here
});

Acceptance Criteria

A working to-do list
Tests for (at least) each user story
A responsive, mobile-first design
Ensure your app is accessible to as many different users as possible

spikes

Advanced CSS

How can we use advanced CSS features to create complex custom components?

Questions to consider

What are "combinator" selectors? Can you provide examples where they're useful?
What are pseudo-elements? Can you provide examples where they're useful?
How might you create custom-styled checkboxes using both of the above?

Useful resources

Advanced DOM

How can we use advanced DOM features to make rendering complex UIs easier.

Questions to consider

What is a NodeList?
- How is it different from an array?
- What's the different between "live" and "static" NodeLists?
What is the <template> element?
- How can we use this to render dynamic UI?

Useful resources

Checking our code

What are all the different ways to make sure our code is correct?

Questions to consider

What is Prettier? How might it help us write better code?
What is static analysis? How can a linter help us avoid bugs?
What are the pros and cons of unit, integration and end-to-end tests?

Useful resources

Testing methodologies

How do different testing methodologies try to improve the way we write tests?

Questions to consider

What is Test-Driven Development (TDD)? Can it help us write better code?
What is Behavior-Driven Development (BDD)? How do we translate user requirements into automated tests?
What is test coverage? Can this tell us about the quality of our tests?

Useful resources

These resources are helpful extra reading that may clarify or enhance concepts you're learning in the main curriculum.

Good testing practices so you can be confident your tests are working.
A comparison of creating DOM elements manually versus using the <template> element. Useful technique if you're dynamically rendering lots of stuff with JS.

docs

Contributing to the curriculum

Our curriculum is open source, and we invite contributions from our learners, alumni community, and even external contributors. We would like potential contributors to follow our process, as laid out in this document.

Opening issues

GitHub issues are central to our process. No work should be done on the curriculum without first being captured and discussed in an issue. This ensures the team are on the same page, have a chance to discuss suggestions, and can assign work to the appropriate people.

Please do not start working on the curriculum without engaging with the team first. This means opening an issue if you can't see one already present, or commenting on the existing discussion to express interest in the work. Opening a pull request without engaging could lead to you wasting your time if the work is not relevant, or duplicated, or otherwise does not fit the teams's goals.

Pull requests

Once you have established that a contribution would be welcomed please open a pull request with your changes. This will allow the maintainers to review your work and provide any feedback.

Try to follow good Git practices—divide your work into granular commits with descriptive messages. Use the pull request description to describe the high-level changes (screenshots are often helpful), and why the changes are needed.

The maintainers may provide suggested changes in their feedback—please don't take these as personal criticisms. It is important to us that new curriculum material meets a high standard, and is consistent with the existing material.

Workshop contributions

If you are writing an entirely new workshop it is important the material follows the same structure as our existing workshops. Read through some of the current curriculum to get a sense for how these are written, and try to match it.

Balance

Workshops should have a balance between explaining new concepts and allowing learners to practice and figure things out on their own. If a concept is new to the learners, and is very important to understand correctly, then explain it clearly and in detail. For more minor concepts it is a good idea to lead learners to the right conclusions through examples or challenges.

Examples

Try to keep code examples minimal and focused. Don't include extraneous surrounding code unless it is absolutely necessary for understanding. Make sure the code is clear, with descriptively named variables. Try to do things in the most "normal" way—avoid overly clever solutions that force learners to stop and think about them. Remember that learners are likely to use example code as the basis for their projects, so make sure it is robust. If there are edge-cases or important things left out for brevity make sure to highlight this.

Challenges

Try to keep learners engaged by using interactive "mini-challenges" throughout the learning material. Sometimes it is unavoidable that learners have to read through a longer technical section to absord a new concept. Try to break this up by having them try out new things, even if just in the console of their browser. These challenges should not require lots of deep thinking or time investment—they are just to help concepts sink in and maintain learner engagement.

These mini-challenges should have an expandable solutions section inline so learners can quickly verify their work without spending too long on each section.

Learnings should be reinforced by more in-depth challenges at the end of major sections. This is where the real learning happens—these should reinforce the information just presented and require the learners to reflect back on the information and apply it in a potentially novel way. Ideally the challenge should require a certain amount of repetition to ensure the knowledge sticks.

Curriculum intent

This document explains the high-level intent behind our curriculum—the motivations behind decisions and trade-offs we have made, and what we expect learners to get out of it.

Scope

Our programme has limited time to get learners from understanding the basics to working as professional software developers in a Level 4 apprenticeship. This means we have to make strict decisions regarding what concepts to cover in the curriculum.

Software development is a hugely broad discipline, with hundreds of different programming languages and paradigms to write code within. Our curriculum is specifically focused on writing software for the (World Wide) Web. This means we exclusively use the languages native to the web—HTML, CSS and JavaScript (with a little SQL included as it is the closest thing to a standardised language for data access).

We focus on full-stack web development, which means primarily application code. Our programme is designed for people who want to build web applications—this includes both client-side and server-side code. We do not focus on building native applications, systems programming, hardware, or other lower-level concepts.

Accessibility

One of Founders and Coders' founding principles is to improve access to the tech industry. Our curriculum is therefore designed to be as accessible as possible. All of the languages and technology we use and recommend are free and open source. All a learner should need to get started is access to a computer and an internet connection. Our resources are explicitly focused on people without an existing technical background, and should never require prior expertise or academic qualifications in computer science.

Broader learning outcomes

Each topic in our curriculum has specific learning outcomes that directly relate to it. Since it is unusual for even a full-stack software developer to be an expert in every area of their role we treat each curriculum topic as an introduction to the fundamentals that can give a learner insight into whether they would like to move deeper into that area. However the curriculum as a whole has some broader learning outcomes that are encouraged through its structure that are important and relevant no matter what a learner's eventual focus becomes.

Self-sufficiency in learning

Software developers are required to constantly learn and implement new things. The job requires a strong skillset in research and self-learning. Our curriculum encourages this by not "spoon feeding" everything learners need to know. It includes dedicated research time where learners can develop these skills, and projects where they must create solutions to novel problems on their own.

Language fluency

We expect our learners to use HTML, CSS, JS and Git fluently by the end of the course. These languages and tools should feel second nature after using them every day for months. The faster learners can become "fluent" in a programming language the sooner they can focus on higher-level concepts instead of struggling to understand the language the concepts are written in.

Teamwork

Our programme includes very little individual work. Workshops are often completed in pairs, research is undertaken and presented in groups, and projects are completed and presented in groups. Our learners enter the workplace with a huge amount of experience in working within the roles of a modern agile software development team, which is almost an important skillset as being able to code.

Balance

As an apprenticeship training provider it is important our curriculum meets the needs of the industry our learners end up working within. At the same time we are aware there is a tension between what might be best for a learner's journey and fundamental understanding versus what is most immediately useful for a business.

We try to strike a balance between focusing on lower-level fundamental learning and higher-level abstractions like frameworks that allow junior developers to be more immediately productive at work. We do not want a focus on employability to compromise our learners' longer-term conceptual understanding.

Our policy is to teach one or two "levels of abstraction" below the industry. For example a lot of modern web development uses "meta frameworks" like Next.js, Sveltekit, Remix etc that are built on top of an existing framework like React or Svelte. Whilst our curriculum touches on meta frameworks it focuses more on the fundamentals directly below this—understanding the React framework, and the browser DOM below that.

At the same time we don't worry about students learning abstractions that are unlikely to be useful to them if they don't contribute much in extra understanding. For example we stopped implementing our own HTTP servers in raw Node.js and now use the Express framework to handle lower-level routing.

Curriculum process

This document describes the process our organisation follows to maintain the curriculum, from fixing day-to-day issues with workshops to making high-level structural changes.

The curriculum circle

Founders and Coders maintains a "curriculum circle". This is a group of maintainers who are responsible for the health of the curriculum. Currently this is made up of permanent employees, but in the past has included alumni who helped on a volunteer basis.

The curriculum circle meets fortnightly to discuss and assign any work the curriculum requires. All problems, suggested changes and discussions should be captured in issues raised in this GitHub repository. New issues (or anything that has become relevant/urgent) should be tagged with the "Next circle" label to ensure it is discussed. Since the curriculum is open source these issues can be raised by anyone.

The circle will discuss any relevant issues and make decision on what work (if any) should arise from it. Issues are then assigned to a member of the team who is responsible for ensuring the required work is completed.

Feedback

We receive feedback on the curriculum is several ways:

Issues raised directly on this repository
The weekly feedback forms our learners complete
Points raised in each cohort's weekly "Stop Go Continue" retrospective sessions

Any feedback pertinent to the curriculum will be translated into an issue in this repository so it can be discussed in the next curriculum circle meeting.

Changes

Although the curriculum is open source the final discretion for changes lies within the Founders and Coders team (specifically with the Developer-in-Residence role). This ensures the curriculum maintains a consistent direction and a cohesive approach, rather than becoming a fragmented collection of semi-related material.

coursebook

FAC Curriculum

Running locally

Git hooks

archive

Node & npm introduction

Node JS vs Browser JS

Installation

Using Node

REPL

JS files

Node package manager

package.json file

npm init

npm install

npm scripts

developer

Programming Paradigms

The different programming Paradigms

Imperative Programming

Real-world Example

Coding Example

Declarative Programming

Real-world Example

Coding Example

Declarative vs Imperative Programming

The Pro and Cons of Declarative Programming

The Pro and Cons of Imperative Programming

Reactive programming

How does it work?

DevOps

Further reading

handbook

Asking for help

Quick summary

When to ask

How to ask

Describe the problem

Include some code

Stay engaged

Coaching groups

Schedule

Two different modes

The roles

Proposer

Respondent

Observer

Starting

Ending

Tools

Code review

How we code review

Before code review

The reviewing process

Raising issues

Review etiquette

Course rules

Respect each other

Avoid microaggressions

Avoid unnecessary corrections

Don't pretend to be surprised

Debugging

You're not a bad developer

Understanding the problem

Read the error

Google the error

Ask an AI

Fixing the problem

Make sure your code is running

Change one thing

Track attempted solutions

Ask for help

Employment schedule and material delivered in FAC20

In pairs from previous project teams

In React pairs

With TfB team

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

With week 1 team

GitHub Workflow

Glossary or terms

`package.json` file

`npm init`

`npm install`