> For the complete documentation index, see [llms.txt](https://fundamentals.rocketacademy.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://fundamentals.rocketacademy.co/course-logistics/course-methodology/course-components.md). # Course Components SWE Fundamentals applies a flipped classroom model that consists of 2 components: **self-learning** and **live classes**. ### Self-Learning The goal of self-learning is for students to learn concepts **before** class, such that class time can be spent discussing those concepts. **Self-learning is mandatory**, and will consist of videos and exercises listed under the Pre-Class header. ### **Live Classes** The objective of live classes is to enable students to gain a better understanding of the concepts learnt during self-learning through instructor facilitated discussion and pair-programming exercises. **Live classes are mandatory.** They will be held over Zoom. There will be 1 pre-course briefing and 12 classes in total. Each section will have their own Zoom room to meet for live classes. Live classes will generally follow this outline: 1. 30 minutes for students to explain and review concepts with the section 2. 85 minutes of pair programming on in-class exercises with a designated peer 3. 5 minutes for students to ask any questions that they might have about the day's class, and for the instructor to preview the next class ### Pair Programming Pair programming is a common software engineering activity that involves 2 engineers working on the same computer, on the same problem together. Typically, 1 engineer acts as the "driver", controlling the keyboard and writing the code. The other engineer acts as the "navigator", helping to guide the overall strategy and look up documentation (on a separate computer). Pair programming is commonly used for the following purposes: 1. To share knowledge across teams or between juniors and seniors, where the navigator is typically more knowledgeable about that part of the system than the driver. 2. To ensure an important piece of software gets done correctly. Sometimes, for difficult software engineering problems with large future repercussions, it is more worth it to spend 2 engineers' time to get it right, than to spend 1 engineer's time and risk getting it wrong. During SWE Fundamentals, we will use pair programming to solidify our understanding of concepts by coding and explaining in front of each other. The majority of class time will be spent pair programming in designated pairs that will change every live class. ## Exercise, Project Strategy Please read through all sections of exercises and projects before starting. Later parts of exercises and projects may require different code architecture than earlier parts. **Failure to take into consideration all aspects of the project might result in a lengthy refactor.** ### Base, More Comfortable To accommodate different learning speeds and prior experience, exercises and projects may have different sections to differentiate what must be completed to minimally understand concepts, and what are extra exercises or features to help solidify one's understanding. #### Base Everything in the Base section must be completed to minimally understand relevant concepts. When short on time, we can complete the Base section then move onto the next exercise or project. #### More Comfortable The More Comfortable section is for students that wish to push their boundaries. Students can complete SWE Fundamentals without touching More Comfortable, but students that complete More Comfortable exercises will gain more experience and may be more valuable in the job market. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://fundamentals.rocketacademy.co/course-logistics/course-methodology/course-components.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.