The Null Professor (2014)
tagide.com
tagide.com
There may, perhaps, also be an inherent aptitude component as well. I still sort of think that there probably is. But we still shouldn't confuse that with what's really going on in the intro classes. Some kids that have the aptitude, and still have the potential to become exceedingly competent, should not be weeded out just because they didn't have the good fortune to be exposed to CS before college.
[1] Full disclosure: HMC alumn
But then there are those manic musicians. A real musician must play everyday, regardless if he has audience, if he gets payed, if it sounds good to anybody but him. A real musician is manic and becomes depressive, if unable to make music. Some of them become great musicians.
Its the same with coding. Most people are to shy to try even. Lots of people fail to get traction. Only a few become manic, and of those a some become great coders.
The issues of pedagogy whether it is music or programming are largely sociological.
So why not make being a manic musician attractive and marketable like they do in movies about music?
I guarantee you that the core inspiration that starts (and to a large extent sustains) any involvement in any activity is aesthetic. This makes aesthetics the beginning and end of activities.
But in programming, we just use the manic people as Golden Children to somehow whip the other students into shape. This utterly fails of course, aesthetically and practically and in every other way imaginable. It's an ugly way of doing things and it doesn't actually produce good programmers.
Probably not.
I've taught both programming and guitar over the years, and in the end, those that endure the frustrations and loneliness of learning, because of whatever-inner-drive, have become successful, although it would seem that in this context, the word "successful" is perhaps fairly arbitrary, which also may be at issue here.
It really isn't much more complicated then that.
I just cannot see any shortcut in learning to play guitar besides actually playing an hour a day, with very sore fingertips and sounding like crap, for months, although, of course, my encouragement and beginner-level instruction in how to play "Seven Nation Army" and "Brain Stew" is, at some level, probably sort of helpful.
Same with learning Python/C/JS/etc.
I have always loved the term grok as a wonderful descriptor of gaining these type of skills and knowledge, as it captures the essence of the idea almost perfectly.
[edits]
A language is like an instrument, once you know one, learning the next will be much easier, because you already know about rhythm and harmonics. Each new instrument, even a new guitar, is a ear opener, as it forces one to play different, to learn fresh.
Same with programming languages. Learning a new language becomes trivial after the first dozen. But each new one widens the way one see code.
Somewhat later in the post, the word can even be clicked upon. I honestly hoped that the link would explain the specifics in teaching methodology, but it was simply a link to the Wikipedia page about the term.
Good teachers use pedagogy. Bad teachers, which are 'Null Professors', don't use pedagogy. Simple. The author herself once didn't use pedagogy. Now she does. She understands now.
The article then turns to a question: "Why student's don't get it". This also is easily answered: educators should use "problem-driven and hands-on [methods] rather than abstraction-driven".
What you are fishing for is "how to teach", whereas Crista post is simply pointing out that "you have to learn how to teach". It is a bit circular, but in university most professors come in without any formal training on how to teach undergraduates; the idea that you have to learn how to teach is still quite radical.
Take a look at Teach Like a Champion 2.0 by Lemov. It answers this precise question! (http://www.amazon.com/Teach-Like-Champion-2-0-Techniques/dp/...).
But there are plenty of students who don't, and they're the ones left out. They have no idea how to program, and the useless programming course won't help them, because for the past 30 years most of the students taking it have already known how to program, so the people designing the course have no idea as to its actual quality. The professors see them struggling and assume they just "don't get it".
It's this which also causes the massive gender bias in CS students: male students, to whom early (and current) computers were marketed, had learned to program at home. Female students, to whom home computers were never marketed, mostly didn't learn to program at home. So they take the course, are considered by the professors to "not get it" unlike most of their male peers, and drop out: http://www.npr.org/blogs/money/2014/10/21/357629765/when-wom...
> First, after the first few years of being a professor, my conclusion was the same: there’s nothing I can do, some students get it others don’t. I’ve learned a few things since then, and I know I was completely wrong. I was being a “Null Professor” at the time. Now I know better.
...
> A Null Professor is someone who never has to think about pedagogy. The Null Professor is not necessarily a bad professor, although that may happen too; it’s just that he/she doesn’t think about pedagogy, teaching comes as whatever natural teaching skill he/she has.
He said that no matter how good we will be, in CS half of our (high school) students will not learn much, if anything.
I was (and still am) absolutely shocked about this statement.
He claimed that this was a unique property of CS. If such a thing would happen in any other subject the teacher would be a total failure. But it would happen to him in CS, every college and every teacher in education he was ever responsible for.
This person is responsible for the education of teachers, engaged, probably very well thought and I have every reason to believe him to be a very good teacher. I'm don't know what I should think about this.
But The link at the end is really not helpful.
>At Harvey Mudd we’ve focused on changing four things about learning CS: make it fun, make it relevant, make it not scary and make it clear that lots of kinds of people have careers involving CS. We changed the context of the intro course to “creative problem-solving in science and engineering using computational approaches with Python” instead of “learn to program in Java” and made sure that the homework assignments were a lot of fun. We did not reduce the level of rigor or challenge, and we increased the amount of programming.
So, you made CS less like math. That good for some. But you completely ignore that math education does not suffer these problems. Why not making making it more like math? Well, in the end AFAIK neither works. At least for worse half of high school students.
Here is a discussion of a paper (with link to the paper itself) that looks at these issues: http://www.tjradcliffe.com/?p=1338
And some follow-on, where I build a simple model that reproduces the biomodal mark distribution under the assumption that there is a single characteristic that is uniformly distributed amongst the population but that exhibits a threshold when it comes to programming: http://www.tjradcliffe.com/?p=1471
My bet is there's one (or a small number) of characteristics that are possessed in different degree by people and that if you fall below some threshold you will have a hard time learning to code. I liken this to height with respect to getting over a wall in an obstacle course: for people who are tall enough, it'll be easy. For people below some threshold it will become increasingly hard. There are two other variables that matter (strength and weight) so it may be difficult to pull out height as a single parameter, but some linear combination of height, weight and strength should be a good predictor of ability to get over the wall.
No one has found such a small set of factors for programming ability yet, but I'm not aware of anyone testing the things that are likely to be important, particularly a) ability to follow instructions; b) ability to create a set of instructions for a task that, when followed by a person unfamiliar with every element of the task will result in its successful completion; and c) ability to arbitrarily use anything to represent anything else.
Which, I believe, also hold true with learning to program.
Like anyone who has pursued a diversity of interests fairly seriously over decades, I've found that some things are really easy for me, others not. I'm an excellent poet, if I do say so myself, and although I've worked hard at it, it comes easily to me. But after forty years of steady practice I'm pretty sure I will never be much of a prose stylist, no matter how hard I work at it. I can tell a decent story, but when I look at people like Iain Banks or David Mitchell I recognize that they "get it" in a way I probably never will, no matter how much effort I put in.
So the belief that force of will can overcome all obstacles is not one that I subscribe to. It can help, but some obstacles are simply too big. It is an open question if this is often the case with regard to learning to code, and while I think it is, the lack of any independent measure of "getting it" makes my position implausible. As such, all that would take to convince me otherwise would be a way of teaching CS1 that didn't routinely result in the traditional bimodal mark distribution.
I totally agree with this, and, if fact, it I were totally honest I would say that I took up programming at 15yo because it came easily to me and seemed like a great way to make a living, although performing music was my true love.
I am not saying " force of will can overcome all obstacles", but I am saying if someone wants to overcome their obstacles, there should be no additional ones placed in their way just because they are on the wrong side of the "bimodal mark distribution" curve.
There was an article posted that showed that you could predict performance in introductory CS from a single test given at the beginning of the semester. There were 3 groups:
1) the group who understood about rules, applying them to a computing system and had the correct interpretation of them--they did well unsurprisingly.
2) the group who understood about rules, applied them consistently, but simply had the wrong rules internalized. They did well after being taught since all you had to do was correct the wrong rules.
3) the group who simply didn't have any logical understanding of how to apply underlying rules to a system--they simply failed miserably. To teach these people CS, you first have to teach these people logical cause/effect thought. This is so fundamental a building block that you can't possibly cover it in a CS course. So, to a first approximation, these people actually can't be taught because you have to fix something else first.
And, that problem, I suspect, is actually buried in the article:
"give me a fake problem, and I don’t think it’s worth my time; my brain shuts off. I suspect a lot of people (especially women) are like me."
When faced with this situation, some of us get told: "Tough. Suck it up. You don't always get to do interesting things, and you have to succeed even if it's boring." Others of us get sympathized with and are allowed to slack with excuses like "Math is hard; I wasn't any good at it either." A couple iterations of this and you wind up with a gap in final achievement even though there is no gap in initial ability.
If I were throwing around stereotypes like the author, I would say that "Men get told to suck it up or get out. Women get sympathy and are allowed to stay and make excuses." And thus you wind up with an achievement gap between men and women.
It's great to contend that everyone can be taught to program, but decades of research have yet to answer the question of "How?" Or even "Why?" Many people have very strongly felt opinions, but there is a surprising paucity of data.
The idea that some people get it, some don't is not at all ridiculous: it is a perfectly plausible hypothesis given the robust bimodal mark distribution seen in first year computing, which differs from what we see in math or the sciences. The problem is no one has been able to find anything that correlates well enough with this to be predictive, and if "not getting it" and "getting it" were features of humans we might expect to be able to measure them in ways other than teaching first year computing.
On the other hand, no one has ever been able to get rid of that bimodal shape (so far as I know), so there is an equal and opposite knock against that hypothesis.
I lean toward the "inherent" hypothesis and have some ideas as to what might underlie it, but would be easily convinced otherwise if anyone could actually generate an intro computer curriculum that resulted in a mark distribution that looked more like what we see in first year math or physics.
However, I must agree with the notion that some people inherently can't program. To take the most extreme case, do you think the dumbest human on earth could learn to program? I don't. All concepts require some level of intelligence to grasp. Many animals have some intelligence, but cannot learn how to count. Humans know how to count because humans originated the concept, and therefore the first human to do it must have had some intrinsic ability others lacked. Teaching can spread the insight, but it cannot create insight from nothing.
I will go one further to say some people who can't program make it into universities. Admissions aren't perfect. People can get in because of their parents, because the school wants them as an athlete, because of Affirmative Action, or a simple misjudgement by university staff.
I think people lose sight of this because intelligence and knowledge are so hard to measure. Footraces are much easier because you can only measure speed against a clock, and I know most humans will never have the ability to run a 4 minute mile. No women has done it yet.
This is not to say this makes some people "better" than others, but everyone has their own skills. It is folly to think everyone can do anything anyone else can do, even in principle.
No. Just no.
First, the study linked to is indeed an interesting finding on neuronal differences between men and women... that is easily twisted to justify existing stereotypes. It doesn't actually say anything about FUNCTIONALITY - just anatomy. But it's easy for the author to connect those dots, despite no scientific basis.
Second, there are no "white male-dominated learning paradigms" that are SPECIAL to computer science. Women have achieved parity in biology, despite "white male-dominated learning paradigms" there, and women have achieved dominance in psychology, again despite "white male-dominated learning paradigms". Those show that such "paradigms" are not the issue.
Honestly, after such a thoughtful article, I was disappointed it ruined itself so thoroughly at the end.
For example, dolphins have tails and flippers while I have arms and legs. No one disputes the dolphin is a better swimmer and I am the superior runner.
Why should this be any different with brains? Brains with different structure are suited to different things.
To me, it says "your marking scheme for graduates is broken".
The entire purpose of marks is to classify the people taking the course. Or, to put it another way:
When everyone is super, no-one is.