My initial thought is that it is saying that it is OK to omit some details if they would only serve to confuse learners based on what they currently know?
for example - I volunteer with CodeNation teaching HTML/CSS/JS to high school students and we don't explain that `$` is an alias for the `jQuery` object, or any other details about it - because they don't need to fully understand that to start working with it.
Their mental models aren't sufficiently complex enough to truly understand the truth, so don't bother peeling away the layers of abstraction, just teach them what they need to know to be successful. Eventually, as they advance, they'll gain a more complex understanding, and get closer to the truth.
to light an LED. They don't need to know that the led class is inherited from a generic output device. They don't need to know that the `on` method means the gpio pin they are using is `high` or that it's outputting around 3.3V. They just need to know that when they run the code, the LED turns on.
When/if they go on to learn more, the layers of abstraction can be removed and they can learn more about what is going on under the hood.
I've always felt US mathematics education is a case study in what happens when "lies for children" goes terribly wrong because the teachers never actually encounter a version of the field that isn't a lie.
My experience volunteering in an AP CS class makes me wonder if something similar is happening in K12 CS at the moment. The students knew by heart the JavaDoc for String.format but struggled with loops. The teacher also struggled with simple nested for loops. Kind of made me want to throw away the damn laptops and just spend some time solving problems on pencil and paper...
Nothing but praise for Greg's work, I've worked with him in person and his evidence based approach works wonders.
Apply the lessons in the book anytime you need to teach people then you'll realize how much time you wasted before. Many of the lessons are not limited to technical subjects either.
Building a concept map, for example, forces you to distill what you're trying to teach instead of trying to cram as much knowledge as you can into a lesson.
I'm curious to see some examples of rule 6
> Never hesitate to sacrifice truth for clarity.
My initial thought is that it is saying that it is OK to omit some details if they would only serve to confuse learners based on what they currently know?
for example - I volunteer with CodeNation teaching HTML/CSS/JS to high school students and we don't explain that `$` is an alias for the `jQuery` object, or any other details about it - because they don't need to fully understand that to start working with it.
You're absolutely right. It's basically lies to children (https://en.wikipedia.org/wiki/Lie-to-children)
Their mental models aren't sufficiently complex enough to truly understand the truth, so don't bother peeling away the layers of abstraction, just teach them what they need to know to be successful. Eventually, as they advance, they'll gain a more complex understanding, and get closer to the truth.
When teaching physical computing I use a python library called gpiozero (https://gpiozero.readthedocs.io/en/stable/). This lets kids write code such as:
to light an LED. They don't need to know that the led class is inherited from a generic output device. They don't need to know that the `on` method means the gpio pin they are using is `high` or that it's outputting around 3.3V. They just need to know that when they run the code, the LED turns on.When/if they go on to learn more, the layers of abstraction can be removed and they can learn more about what is going on under the hood.
I've always felt US mathematics education is a case study in what happens when "lies for children" goes terribly wrong because the teachers never actually encounter a version of the field that isn't a lie.
My experience volunteering in an AP CS class makes me wonder if something similar is happening in K12 CS at the moment. The students knew by heart the JavaDoc for String.format but struggled with loops. The teacher also struggled with simple nested for loops. Kind of made me want to throw away the damn laptops and just spend some time solving problems on pencil and paper...
This is an amazing resource. Thank you!
Nothing but praise for Greg's work, I've worked with him in person and his evidence based approach works wonders.
Apply the lessons in the book anytime you need to teach people then you'll realize how much time you wasted before. Many of the lessons are not limited to technical subjects either.
Building a concept map, for example, forces you to distill what you're trying to teach instead of trying to cram as much knowledge as you can into a lesson.
This is useful to me. Thanks!
Corrected URL: http://teachtogether.tech/
Fixed. Thanks!