Skip to main content

Final Projects

Learning Goals​

During the Project you will work on your technical and communication skills. At the end of this module you'll learn the following:

Technical skills:

  • How to build a complete full-stack application
  • Understanding how each part of an application relates to each other
  • What it means to work on a feature
  • How to work with Git in a team setting
  • How to write readable code

Communication skills:

  • How to communicate effectively with team members
  • Keeping track of your project's progress
  • Knowing if you understand what's asked of you
  • How to communicate with non-developers about what you're doing
  • Learning how to be solutions-oriented
  • How to work in a Agile setting

Objectives​

The final projects form the final module of the course, comprising four weeks following the completion of the last teaching-based module (currently the database module). The objectives of this module are to:

  • Bring together everything the trainees have learned so far (most projects involve a Node/Express backend with a database and a React frontend);
  • Give an opportunity to demonstrate teamwork and a mix of interpersonal and technical skills that the trainees can talk about when applying for jobs; and Deliver something valuable for CYF or a partner organisation.
  • Also: nice portfolio piece; practice agile stuff; practical experience of junior dev role.

Project team

Ideally, the project team would consist of the following:

The mentor group would include an engineer (responsible for unblocking technical/architectural issues, not an extra developer), designer (responsible for user research and UI/UX) and product manager (responsible for prioritisation and alignment with the product owner’s goals). This gives an opportunity to bring in volunteers from the broader tech community, and exposes the trainees to the roles they could be collaborating with in employment.

More information on volunteer roles

The product owner would either be a representative from the partner organisation or someone at CYF, depending on the project. It’s important that they are able to engage at least twice a week with the team, and have the authority to make decisions that let the team keep moving.

Weekly plan​

We’re going to run the final projects in weekly “sprints”, planning out what we’re going to do as teams and as individuals. Each week will therefore look something like:

  • Daily standup: post a daily message in the team Slack channel to let the rest of the team know what you’re working on, what progress you’ve made (even, and perhaps especially, if it’s none so far) and share anything that’s blocking you. Set a time for this and stick to it. Don't forget to also read your team members updates and try to help them when they are blocked. Afterwards, post a team summary in the main class channel.

  • Mid-week check-in: you should have at least one Slack call with the whole team and a mentor during the week to sync on progress, escalate any blockers and make sure that you’re still heading in the right direction.

  • Classes: we’ll continue to meet on class days where we will be spending time on:

    • Demo: integrate all of your work together and share your progress so far with the mentors.
    • Retrospective: what’s gone well this week? What’s gone badly? What are you going to do differently next week to make things better?
    • User research: show what you’ve built and what you’re planning to build next to potential users (other trainees, mentors, etc.) and use any feedback they have to improve your plans.
    • Sprint planning: decide what you’re each going to be doing during the following week and where you want to be by the next class.
    • Technical support: mentors will be on hand to help you get unstuck from any blocking technical issues.

Contributions Check In​

It's important to evaluate our contributions to the group. Here's what we expect:

  • Roughly equal pull requests (PRs). That is, we do not expect everyone to open the exact same number of PRs or commit the same number of lines of code, but we do expect features to be fairly evenly shared. As a quick guide: in a group of four, no one commits more than 33% of the features and no one commits less than 20%. These contributions will be measured with a tracker similar to this template
  • Sometimes PRs are not merged, as the project develops and your understanding of the problem domain develops with it. That is absolutely fine and normal. It is still important that you show your work.
  • A full stack developer must deliver features that touch each part of the stack. This means at minimum you must build a component of UI that interacts with the database and you must configure and manage that entire process. At best this means multiple features across different parts of the stack.