The most fundamental thing about teaching is that the students are, by and large, not like you.
When you teach, try not to be too clever. People always want to know the latest. And we love to tell people the latest. The problem is that most people who ask for this haven’t learned the foundational stuff. It’s not just to show them something they have to understand.
Education is what, when, and why to do things.
Training is how to do it.
But… don’t show off. I mean, it’s so tempting to show off to our colleague, to stand in front of a group of people and show them something: “Look, this is clever, you don’t get it, right?. (That means I’m smart)”. That is not good teaching.
When you do it right, people come out and say: “ugh, that was easy”.
We have to keep our egos in control, remembering that the purpose of the exercise is to teach somebody else something useful.
Teach people how to do the basic things, teach people to do simple things. When you’re illustrating a technique, don’t use the most advanced algorithm you can find. The best example is the simplest example that illustrates a technique or a feature or something. In teaching, simplification is a really important thing.
You can’t just lecture about programming
There is never time to do the job right, but there is always time to fix it later.
Programming it’s a practical skill, I sometimes say:
Do you think you can learn tennis from a youtube video?
Do you think you can learn design without designing things?
Programming without writing code?
People do believe those things and that’s wrong.
Code:
Don’t separate code from explanation, if you just show the code, people will not get the idea and they will invent reasons why it looks like that and those reasons are sometimes seriously weird.
On the other hand, if you give them just the explanation, they don’t get the idea. So, tight integration between examples and explanation is essential.
Always give reasons:
In the next example, why is [2] better than [1]?
1.
int len = v.size();
for(int i=0; i<len; i++) ...
2.
for(auto x:v) ...
Reason: [2] directly states the intent of the code
- Can easily be changed to use an algorithm
- is shorter, gives less oportunities for errors
Note: [1] is more general, can express more cases. That’s why we avoid it.
Better code
22 years ago, after almost 10 months of travel to Mars, the $125 million Mars Climate Orbiter burned down and broke into pieces because someone failed to use the right units
Teach good practices, eg. make interfaces precisely and strongly typed.
void blink_led1(int time_to_blink){
// bad - the unit is ambiguous
}
void blink_led2(milliseconds time_to_blink) {
// good - the unit is explicit
}
blink_led2(1000) //fail
blink_led2(1000ms) //good
Excellent article. I’m dealing with a few of these issues as well..
Thank you Shaniqua 🙂