Active learning is at the heart of our educational philosophy. It is about encouraging learners to build, explore and discuss new concepts instead of being passive recipients of knowledge.

The idea behind CodeYourFuture started brewing in the summer of 2016. Working in the tech industry, CEO and co-founder Germán wanted to find a way to make a positive impact on people’s lives through technology. He had observed the invaluable contributions of developers to organizations of various sizes and saw the potential for empowering individuals with coding skills.

During the European refugee crisis of 2015, the UK experienced a negative perception toward forcibly displaced people, despite many individuals lacking personal interactions with refugees or asylum seekers. Seeking guidance, Germán connected with Gijs Cortens, the founder of HackYourFuture, who provided valuable support during the early stages of establishing CodeYourFuture.

In mid-October 2016, CodeYourFuture launched its first class with ten students from diverse backgrounds, including Syria, Afghanistan, India, Ethiopia, and a stateless individual. This marked the foundation of the London chapter. An article published in Refugee Deeply provides a detailed account of the launch of the first class. When interviewed during the launch of the first class in 2016, German said:

“The tech industry is facing a huge challenge to find developers to fill the ever-increasing number of vacancies and, at the same time, to increase the diversity of their workforce to help serve their customers better,” he explains. “Training refugees to become developers represents a great opportunity to address both issues.”

CodeYourFuture expanded its focus in 2019 to include locally-born disadvantaged adults. Many of these adults face challenges in finding meaningful work in their home country due to a lack of resources. CodeYourFuture aims to bridge this gap by providing them with essential skills and opportunities.

In software development, we break down complex projects into smaller, manageable parts, which we work on for a week or two. These periods are called “sprints.”

A sprint backlog is like a to-do list. It lists what the team has decided to work on this sprint. It’s chosen from a larger list, usually called the “product backlog,” which holds the entire project to-do list.

The backlog is a set of work designed to build understanding beyond the concepts introduced in the course prep. For your course, we have prepared a backlog of mandatory work for each sprint. You will copy these tasks into your own backlog. You can also add any other tickets you want to work on to your backlog, and schedule all of the tasks according to your own goals and capacity. Use your planning board to do this.

You will find the backlog in the Backlog view on every sprint.

Copy the tickets you are working on to your own backlog. Organise your tickets on your board and move them to the right column as you work through them. Here’s a flowchart showing the stages a ticket goes through:

Join the Global Calendar

Each day has an activity, and each week has a rhythm. We use Google Calendar to keep track of our activities and rhythms. Subscribe to this calendar and schedule your own week.

Each Meet link is permanently available in the calendar event, so you can join at any time in the day, not just the suggested time. It’s a good idea to make a plan with other people to meet at a specific time.

Often learners try to rush through the curriculum by completing the coursework without evaluating their work. However, our ultimate goal is to build understanding and learn new skills. Our coursework is the means of achieving this goal but not the ultimate goal itself. Learning without evaluation will lead to weak or absent comprehension.

Therefore, code reviews are essential for evaluating our work. They aren’t about grading; they initiate a dialogue starting with constructive feedback about a piece of work. This means you reply to the comments and make changes based on this feedback. This is how you develop your skills. The learning comes from reading and responding, from participating in this dialogue.

Code review is also one way we develop professional technical communication, which is one of the most valuable skills we can give people on this course.

👣 Next steps

• Join the #cyf-code-review channel on Slack
• Check the time of the next code review session
• Locate any unreviewed pull requests for a particular cohort

📝 Check

• Check out our guides on reviewing

Codewars is an online code challenge platform that allows users to hone their skills on thousands of katas. The platform is useful for developing problem-solving skills and improving your fluency in a programming language. Another key advantage is immediate feedback. Users can check their programming solutions with pre-built test suites, gaining very quick feedback on their progress.

👣 Next steps

• Join the CodeYourFuture clan on Codewars
• Check out the CodeYourFuture authored collections on Codewars
• Practice a kata 🚀 😎

In practice

• Figure out how to train on Codewars katas and navigate their interface with a training example.

To achieve our mission, we bring people together to build self-empowered communities of learners. To this end, we have 3 community goals for achieving our mission:

We build communities that can self-educate

Self educate means the ability to draw on surrounding resources to learn new skills and concepts. Tech changes all the time. We must develop independent learners who can teach themselves new skills and technologies.

We build communities that can self-coordinate

Self-coordinate means the ability to make things happen with the people we have. Code Your Future isn’t a large company with lots of staff. We’re a community of motivated people who want to help each other. We can’t expect someone else will do everything - we need to make sure we get it done ourselves.

This doesn’t mean we can’t ask for help - we can - but we need to make sure we make the best use of the knowledge and abilities of everyone around us.

If a trainee thinks we need a extra time learning a topic, they should suggest it! If a volunteer thinks a workshop on a topic would be helpful, they should give one, or find someone else who can.

We build communities that can self-evaluate

Self-evaluating means we work out what we’re doing well at, and what we need to improve. If you don’t understand a topic, you should identify this and get help. If you’re expecting to get code review and no one has reviewed your code, you should raise this problem and get help.

Don’t assume someone else will notice you problems and fix them. Every piece of prep, every sprint, every module has learning objectives. Check them before and after you do them. If you aren’t confident you understand the learning objectives, talk about it.

Our curriculum 🧶 🧶 curriculum is a highly structured organisation of resources and tools to guide a community in its educational development. is a FOSS 🧶 🧶 FOSS Free and Open Source Software - anyone can access it and contribute to it. educational project built by members of our community, including volunteers, trainees, and staff. Its purpose is to equip communities with the resources they need to launch a career in the tech industry. The curriculum is our collective solution to the mission of empowering communities to self educate, self coordinate and self evaluate.

Cohorts meet once a week in person. Together, we develop our understanding of the topics we are working on this week. We use a day plan to organise this day. A day plan is an agenda with workshops, study sessions and activities to make the most of our time together.

There’s a day plan for every sprint of every module. Each day plan lists a series of activities, with timings, instructions, and links to resources.

Find the day plan for the first sprint in the first module. Read the day plan. It’s your plan for class day and if you click the times, a countdown timer will start. ✨

We learn best when we ask questions and explore possible answers. Dialogue is a conversation that facilitates this playful exploration: participants listen to each other, share ideas, build on each other’s ideas, and respectfully challenge and evaluate these ideas.

In practice

Code review

• 🧑🏿‍🤝‍🧑🏽 Reviewers on a PR are expected to ask questions and explore the reasoning behind submitted code.
• 🧑🏿‍🤝‍🧑🏽 PR owners are expected to answer the questions and make revisions to their submitted code.

Pair programming

• 🧑🏿‍🤝‍🧑🏽 Drivers are expected to listen to their navigator and implement their directions
• 🧑🏿‍🤝‍🧑🏽 Navigators are expected to talk to their drivers and articulate their strategy

We use a flipped classroom model. In this model, we expect trainees to start building their understanding independently as soon as possible. From the beginning of the course, trainees are expected to prepare and take ownership of their learning before they attend in-person sessions.

Learning something as a complete beginner can be daunting: it is often difficult to know where to start. To learn effectively, we must set clear and measurable learning objectives to direct our education. Objectives should allow us to answer questions like this:

• Which concepts are we trying to understand?

• What skills should I have after my course of study?

• What evidence do I need to demonstrate my understanding?

With clear objectives in mind, we can continually evaluate our progress by checking against these objectives. During the course, you must evaluate your progress against a sprint’s success page. For each sprint, the success view lists all the learning objectives for any prep and workshops. It serves as an overview of your learning outcomes for a sprint. Use this view to evaluate your progress.

A module also has a success page, listing the overall learning objectives set by the Global team. At the beginning of a module, review the objectives to understand what you are working towards. At the end of the module, review again to check you’ve met your learning goals.

📝 Check

• Check you can locate the module success page for the How our curriculum works module

In a flipped learning model, learners are expected to prepare before they meet up as a community. Therefore, regular preparation is essential for our community to self-educate together. In each sprint week, we expect trainees to work on the prep section beforehand to start building their mental model of the week’s concepts.

Trainees should show up to class with questions and problems they didn’t understand from the prep they already did. This means that we can use our in-person time to work together to fix real problems people have!

Early in most day plans, we use the morning orientation to gather the community together. We nominate a time-keeper and a facilitator (if they weren’t already nominated during the week).

Most sections have written down objectives. It’s useful to know why we’re doing something, before we start doing it.

Steps 👣

1. Find a day plan view where the morning orientation is used
2. Read the learning objectives on the morning orientation
3. Volunteer to be the facilitator or timekeeper (you don’t need to volunteer every week!)

Now that you’ve finished the prep for this sprint, find the backlog for the Sprint and work through the items. When you’ve done this, find the Success page for the module, and make sure you’ve completed all of the learning objectives.

There should be a link to the next page (Backlog) at the bottom of this one. You can also get to the Sprint overview page (which links to Prep, Backlog, Success, and anything else relevant) by clicking the name of the Sprint at the top of the page.

Every sprint you do follows this pattern which you should follow. Look at the overview for the sprint, and work through the pages in order.

We don’t lecture trainees during live sessions. We are not against lectures; if you want to deliver a lecture, that’s great! Put it on YouTube and send us the link. Trainees can then watch lectures at their own pace, with captions, pause, and rewind enabled. Trainees also have free accounts kindly donated by Udemy and you can assign any Udemy for Business course.

At The Docs we have to maximise the time we have together, by working in person on projects, hitting blockers, and learning together. We are not a school. We are a community of professionals coming together to share skills and build real things to help people get real jobs inside one year.

Time is very important at The Docs. We try our best to use everyone’s time as well as we can. We want to use our time together to help learners with the things they can’t do at home: debugging, pair programming, code review, and building projects.

CodeYourFuture helps people who need it most to reach their goal of working in tech. We are a grassroots movement that empowers communities with the resources they need to educate themselves and prepare for a career in the 21st-century tech industry.

At CodeYourFuture, our goal is to get our trainees good jobs in tech. Graduation is not the goal. Graduation is a personal achievement on the road towards success, but the goal is a good job in tech. When talking about ‘successful’ graduates, we mean employable, so we define this as a graduate with a good job in tech.

Members of CYF without the right to work are not included in our employment statistics, but we prepare them for this same outcome to help them to be successful in the future.

How are good jobs in tech defined?

Let’s define a good job as:

• A fair, safe, and respectful work environment
• A starting salary around (or above) the median household income, or with clear progression towards this
• Opportunities for career advancement
• Something you are interested in and enjoy

A job is considered “in tech” if:

• Most of the job’s role helps to produce software or hardware, or helps a customer to use technology
• The work done in the job couldn’t be done without some technical background

Some examples of jobs in tech:

• A developer role in any company
• A DevOps/Cloud role in any company
• A product or delivery role in a software development team
• A QA or test role in a software development team
• A support desk role helping customers to use software effectively
• A UX/UI role in a software development team

This is important for a few reasons:

1. It will give you practice to help build your skills.
2. It will help you to check that you understand everything you’ve been taught, as well as why it’s useful.
3. It will provide an example you can use to prove to other people (e.g. employers) that you can do what you say you can do.

Self-coordinating as a community poses challenges. One challenge is working out not just what to do but when to do it. This gets harder when we are working on different schedules. To make things even harder, we use a flipped classroom model: very different from a regular school.

To solve this problem, we use the rhythm of the week.

This rhythm supports trainees to plan their work during the week while still allowing flexibility in people’s different schedules. In a typical sprint week, Tuesday is the starting point with in-person sessions on Saturdays serving as the mid-point in the week. We use Sundays and Mondays to reflect on our learning and finish off any backlog tasks.

In a flipped classroom, we spend our time in class focused on active learning: we need to prioritise time and space for trainees to work on their backlog independently in small groups.

Steps 👣

1. Search for study group on the curriculum website
2. Find a day plan that uses the study group activity
3. Read the instructions
4. Read the learning objectives for the study group

The rest of this module is split into three sprints, which you can complete in your own time: self educate, self coordinate and self evaluate. Each sprint is about how to use the curriculum to achieve each of these community goals. For each sprint, you’ll need to start with the prep to introduce yourself to new concepts before doing the tasks in the backlog to understand how you can start engaging with the community. At the end of each sprint, there is a success page. Make sure you have achieved all of the objectives in the list and check them off.

Ready, head to the self educate sprint

Welcome to the How our curriculum works module. This is a 3-part self-taught module designed for new members of our community to build a solid understanding of our curriculum. You will need to start with this prep section before exploring the rest of this module.

To best understand how our curriculum works, it makes sense to start by understanding the background of Code Your Future and our collective mission. With an understanding of our collective mission, the purpose and structure of curriculum will begin to make more sense.

Ready, let’s go…

We do at least one active learning Workshop every class day. Workshops are group activities where the community discusses, solves and reflects on problems related to their current sprint. They are an opportunity for practice, critical thinking and dialogue.

We collectively develop workshops in this repo: https://github.com/CodeYourFuture/CYF-Workshops/. Check out some examples and raise a PR if you’ve got an idea for a new workshop.