I’ve spent a good bit of my life living and working in places that many of my colleagues would not drive through in the middle of the day with the windows rolled up and the car doors locked, so you’ll have to excuse me if I am a bit cynical about the latest push to teach everyone to code.
I’m not opposed to coding, in fact, I am greatly in favor of it. It is tied with drinking Chardonnay for favorite activity for which you do not have to get naked. I was an industrial engineer in 1982 – so I was into STEM before STEM was even a thing.
What makes me roll my eyes and sigh is where many well-meaning people have completely missed the mark when they say that you don’t really need to know much math to write software. Clearly, they can’t mean all kinds of software because obviously if you write software to do statistical analysis, predictive analytics or whatever the phrase du jour is, you very much need math.
Often, these people are talking about games –
“Kids play games, let’s have them make them.”
That doesn’t necessarily follow any more than,
“I have a liver. I should create a dialysis machine.”
Ignoring the faulty logic for a minute, let me point out that most games DO require math. The people saying they don’t are usually people who are quite successful, both professionally and academically and have spent their entire lives around people much like them. What they mean when they say that, “Games don’t require much math” is
“I took three semesters of Calculus and a course in multivariate statistics and I rarely use any of that in making games.”
I, on the other hand, meet many people who can’t multiply two-digit numbers without a calculator and have never given a thought to the concepts of randomization, ceiling, floor or rounding. The vast majority of these people are perfectly intelligent enough to learn those things if ever given the motivation, time and instruction.
Here are a few lines from a super-simple game, “Canoe World”, I wrote in the past two days. It’s a very common application. You can find it in the Game Design book by Rex van der Spuy and hundreds of other places. You randomly decide who is stronger, the player or “enemy”, one wins the exchange and points change – a pretty standard game component.
function sink(thing) {
// The player’s strength ;
var playerStrength = Math.ceil((food+ health)/2) ;
var rockStrength = Math.ceil(Math.random()* playerStrength*2) ;
// Find out if the player strength is greater than the rock strength ;
if (rockStrength > playerStrength){
// The rock sinks the canoe ;
var lostFish = Math.round(rockStrength/2) ;
food -= lostFish ;
// Player gains experience ;
experience += 1 ;
To compute the player’s strength, I take the average of their food and health points, and round that up. That’s the ceiling function. To understand this, you must have some idea of order of operations – things in parentheses get done first – to understand that first I’m adding the two values and then dividing by 2.
You need to know that having that slash and then a number means to divide by a number.
That is math and not everyone knows it.
A ceiling function rounds up – and to understand that, you need to understand the concept of rounding.
To understand the second statement, you need to know what a random number is, that the * means to multiply. You also need to know that the random function generates a random number between 0 and 1 and realize that is a continuous distribution because there are an infinite number of numbers between 0 and 1.
That is math and not everyone knows that.
You’d have to realize that since the random number function is between 0 and 1, if you just multiply that number by the player strength it is ALWAYS going to be less or equal and the “enemy” will never win. Since, on the average, the random number will be .5, if you multiply by 2, that makes it equally likely the player or enemy will win and gives you a game of chance.
To change the probability of the player winning the exchange, you can make that number larger or smaller.
You need to know that the > means that the thing on the left is greater than the thing on the right.
All of that is math and not everyone knows it.
The people who want to teach kids to code assume that either,
a. Everyone knows this much math – in which case they are OH, SO WRONG! or …
b. That they will work with the minority of students who do.
There is absolutely nothing wrong with option B. I wish you the best of luck with all my heart and will do whatever I can to help.
Most of what I can do to help is make games to teach math, so that more kids will fit with option B.
There is an option C, which intrigues me, and I have heard very few people discuss, which is to teach the math along with coding. That is certainly not impossible – but it would be hard – you would need students very motivated to put in the time and effort and teachers who were able to step back and start at whatever level of math competency required by an individual student.
This whole thing reminds me yet again of the comment made by Dr. Irv Balow, Dean of the UC Riverside School of Education. Frustrated by reading so much research that said under some conditions class size had an effect, under other conditions, not so much, for some students cooperative learning was a benefit, for others it was detrimental, etc. etc. etc. , a student asked,
“Isn’t there anything in education or psychology we know as absolute, unqualified fact?”
After some reflection, Dr. Balow replied, that the only thing he could be absolutely sure of was this :
“All of the simple answers are wrong.”