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