What are we actually teaching?
We can only teach a subset of programming in our syllabus and because we teach React, that means that we teach functional programming. Further, we teach declarative programming. Our strategy is to build a coherent journey in programming that guides our trainees to their final project with the tools to write great React code. After this, they will go off into many different directions, and they should!
We don’t teach them this is the only way, but this is the only way we teach them.
Let’s articulate together our clear and guiding principles.
What don’t we teach?
There’s so much we don’t cover in our syllabus. It’s not always obvious what we skip because it’s out of paradigm, and what we skip because we’re out of time. So let’s notice some things that are missing and say why:
For time reasons
We don’t teach the following topics, though useful and important, simply because we don’t have time to cover them:
- Regex (though we typically mention them in JS1-W3, we don’t teach them or expect trainees to be able to write them)
We have some Codewars collections around these topics.
For simplicity and clarity
The following topics are largely unnecessary for writing code in the style we teach. We omit them for clarity and focus.
- OOP generally
- JS classes and constructors
thiskeyword is famously unintuitive. React changed its API to avoid using this. Since JS classes tend not to be useful without the this keyword, we avoid them altogether.
In general: while we cover basic language features like for loops, we quickly move on to higher order functions and encourage these over imperative strategies. We downplay strategies that mutate arrays, like push, and pop.
What do we teach?
We teach a subset, so what do we focus on? We broadly focus on Declarative and Functional programming paradigms.
When we mentor trainees we guide them with these principles:
Prefer pure functions
Prefer composable functions
Minimise side effects
map, no to
And so therefore:
Prefer arrow functions
super, or an arguments object.
Code as documentation
Expressing ideas clearly in code. Code should be simple, clearly named, and easy to follow.
Name data clearly
numberOfDevelopers.map(developer => ..., no to
xs.map(x => ...
Comments are why not what