am
commented
4 years ago Thank you @kabaros, great writing. I consider this information valuable and found it by chance! What do you think about moving this to a TECHNICAL_DECISION.md file and link it from the README.md? This may give more visibility for other mentors, and eventually, we could register future decisions/changes/improvements that are made.
The syllabus we will teach at MigraCode Barcelona is based on CodeYourFuture Scotland syllabus, which was based on HackYourFuture originally and evolved over the years with ideas from other schools like Founders & Coders, but mainly through the instructors' feedback and contributions.
The idea is that this becomes a starting point but the instructors leading each module can put their own twist on each module if they'd like to by contributing to the syllabus repo.
In this issue, I will discuss some of the general "design" decisions of the course and syllabus. This is based on the experiences of running three courses with CodeYourFuture in Glasgow, and going through a journey of making mistakes, learning from them and iterating.
HTML/CSS: The initial module is about more than HTML/CSS. Students are normally intimidated by the new environment and the course in general, especially that, initially, there are always few students with a background in tech (or Math or Engineering) that seem to be way ahead of the rest. We scaled the module down to cover less topics (but cover them well), and do a lot of Git work, project work and improving communication skills. While it might seem that a lot of topics are uncovered, it's still a massive undertaking by students and give us all a solid foundation for the rest of the course.
Quality over Quantity: Related to the previous point. In our first round, we tried to cover a lot of topics that we dropped after, i.e. CSS frameworks, templating in Node, ORMs, some React advanced topics etc.. We realised this was not the right way to go. We concentrated on fewer topics after, and acknowledged that better students are always able to go learn themselves once they have the basics, and that going to complicated topics prematurely demotivates the struggling students. We concentrated on fewer topics and reiterated concepts as we go on (for example, keep doing React in the Node module, by letting them integrate their APIs with a React frontend).
React vs. Node: We did React before Node in the first round, then switched the order to have Node before React. The idea behind the switch was that spending more time in Node will hone their coding skills before doing UI/framework-specific work. This didn't work out very well, at that early stage of the course, Node and backend are way too abstract for the students who didn't do coding before. With React (and UI in general) there is constant visual feedback that is very soothing for beginners.
SQL vs No-SQL: We also taught MongoDB in the first rounds of CYF then switch to relational databases (Postgres in our case). The switch was great. SQL is quite generic knowledge, and kind of a fresh start. A lot of students who were struggling with React and Node, found the database module (from database design to SQL) to be a fresh start.
Continuity between React and Node: In Node, we concentrated only building APIs (first without DB then integrating with DB). That was the main topic, and we kept going back to React to connect the API they build so they get a chance to keep practicing React.
The final project: The final project is where 80% of the learning happens in my view. I will discuss that in details, but I think it does help for students and instructors to look at the course as leading to these projects. It helps to know that there is always a chance to learn better topics we skim over at graduation project time, and not be frustrated as student or instructor.
Be agile: We run the course in three-weeks sprints (the modules). We have a retrospective at the end of each module with the students. We take actions from the retro and make sure to implement them. Most importantly though is the spirit of being agile; we are constantly iterating, changing plans, and adapting to the class as we go on. We should not be afraid to do so.
Teaching methods: We experimented with several teaching methods during three classes in Scotland, for example:
Keep the students coming: One of the main challenges during the full course is the varying levels of the students. It's hard to keep the struggling students motivated, while making sure the better ones are not bored. It's important to do so, and to keep people coming and engaged. It's amazing how some things click for different people at different times, if they just keep coming.
As an instructor, Don't be frustrated: While we have to push the students a bit, it's also important to acknowledge the tough challenges that most of them are going through. Don't be frustrated as an instructor if you perceive lack of effort from the students - there is ALWAYS a bigger reason behind it. So let's keep positive and be humble about the difficult journey the students are having in their personal life (there is a lot for us to learn from that), and make it our responsibility to create an empathetic community that keeps them coming even when the coding part is a struggle.