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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Anyone is welcome to contribute changes, as long as they follow the process outlined in our contributing guide.