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)
- Handling null
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.
- Passing by value vs reference
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
Pure functions are predictable. The same input will always produce the same output.
Prefer composable functions
Break up your functions.
Minimise side effects
A function without side effects is pure.
In practical terms this means preferring methods that return new objects, arrays, or values over methods that mutate data. Yes to
map, no to
And so therefore: prefer arrow functions
Arrow functions do not have their own bindings to
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
Prefer verbose and specific naming conventions over algebraic ones so trainees can trace the function. Yes to
numberOfDevelopers.map(developer => ..., no to
xs.map(x => ...
Comments are why not what
Encourage skeleton code in comments as part of development. Then delete those comments as part of refactoring. Use comments to explain choices.
Documentation is expected, simple and routine. Our trainees must practice writing.
Test driven development
Red, green, refactor
Ideally: Requirements are expressed as tests. Production code is only written to pass a test. Implementation details are not tested.