Known shortcomings of the syllabus

[gregdyke]

• Git: "complex" organic git work (working with branches in a typical triangle that produces merge conflicts and necessitates rebases) does not happen until final projects
• Testing: TDD + working with/running test frameworks (jest/cypress, etc.) has not very much been incorporated yet (there are some pre-written tests as part of the coursework throughout most of JS1/2/3, that I expect most trainees do not currently execute them)
• Group work: working in groups does not happen until final projects
• Command Line: progressively learning to work with the command line is not there (things like using the up arrow, tab completion, etc.)
• Http Requests: The overarching picture of "how does the web work, at the http level" tends to not be well covered (though the material is actually nicely spaced over html/css, js3, react and node)
• Revision: spaced repetition (i.e. giving multiple opportunities to work with the same material, spaced out over a number of weeks) is not well done. This gives a "done and dusted" approach to many concepts
• Problem Solving: Too much step-by-step instructions and not enough scaffolding on how to solve problems with code (e.g. working with something like BDD to transform a general statement into a series of examples) - (One of the reasons we would like more TDD is that we think)
• Teaching Javascript: JS1/2/3 are not great modules in a variety of ways/for a variety of reasons. More about that here https://github.com/CodeYourFuture/syllabus/discussions/273. The symptom is that students tend to really struggle around then because we overwhelm them with new stuff
• Module projects: There is a concept of having "module projects": something that trainees would iterate on over a 4 week period, ideally collaborating with others (and increasingly collaborating over the modules)
• Integration with PD: this is a work in progress (that hasn't been started to my knowledge). Many opportunities to work on agile/communication related skills, e.g. by making each (as-yet-not-existant) module project into a sprint, with planning, standup, retro, review, etc.

[emcglackenr1]

Comment from alastair link here I think it's important that they are at least somewhat aware they might turn up at a job and find they're using something else - e.g. GitLab, an internal source control system. Not that we need to talk about those but rather that they understand the tools we're using are choices, not absolutes

[gregdyke]

I absolutely agree that this should be part of the overall git-related learning. It's slightly offtopic from my perspective for "known syllabus shortcomings" for 2 reasons:

• I intended this list as "here are somethings that it's good for everyone to know that we are working with/through/against and that we don't actually have to convince anyone is a problem, because it's already known". In particular, I think it's something that PMs and module coordinators can bear in mind and can help address if they are aware of it.
• The reason most syllabus shortcomings exist is because they require some kind of syllabus-long/multi-module change to address. This particular problem (assuming it's not already addressed by the git syllabus) can be addressed by a PR to the git portion of the syllabus

Where this does fit into a more syllabus-pervasive issue is convincing trainees that our goal is not so much to teach them a specific tech stack as give them the familiarity with fullstack development to be able to easily pick up a new stack/new set of tools. It also fits in more generally with a problem that lots of distinctions between "layers" are not visible until we are able to experience switching out a layer. So for example we never work with multiple databases -> why even do we have a distinction between database server and server? We never work with other protocols than http, so how is the internet different from the http/web part of it?