The guy from the Khan academy talks about that (https://www.youtube.com/watch?v=LnVzug0mA2w), although he suggests going even further-- individualizing each student.
BTW, this is how the children of very wealthy parents often get to elite colleges in quite high numbers. The parents send them to private schools where student-teacher ratios can be as low as 5 (FIVE!). Under those circumstances, each student can get tracked very accurately according to their needs and aptitudes. It is a great way to learn, it works, but is also very expensive.
As someone with a fair bit of programming experience, but who doesn't really do it professionally, I can say that with one of the Intro to CS courses I took on edX, I would have been utterly and completely lost had I none or little programming experience.
Then there can be a pre-100 level course which assumes zero background/experience. Like a CS equivalent of pre-calculus "college algebra" courses offered by many American Mathematics departments. The idea would be that most majors should've already learned basic programming skills in high school, but there's still an option for people who fell through the cracks for whatever reason.
But importantly, this issue is independent of the "geek gene" hypothesis the article is about.
EDIT: Think of teaching at the level of what's in this Atwood post, and the related paper:
https://blog.codinghorror.com/separating-programming-sheep-f...
Isn't teaching programming one way to do that?
Interesting codinghorror link. What struck me was the ineptitude of the question in their example assessment "intended for students who have never looked at a line of code in their lives" ("int a= ..."). It's testing syntax primarily without having taught the syntax, it seems really worthless - all you're really going to test for is who has actually seen some programming and knows that "=" is not equals but is being used as an assignment operator. Surely a proper test for ability in programming would be to write it out in pseudo code like:
integer value a is set to 10 integer value b is set to 20 a is assigned the value of b
what are the values now of a and b.
Supremely facile.
Surely they're not really trying to test ability to guess arbitrary syntax? If they were then they'd be better with
nni a :-# 10
nni b :-# 20
a :-# b
what are the values of a and b?
At least that's not giving a free ride to those who know the previous syntax, they also have to impute meaning on unlearned symbolic strings.Mind you how do you decide to do CS at Uni and not ever have programmed anything??? Sure there's not the degree of crossover that people imagine between the two, but it seems like choosing to do maths without ever having proved a theorem.
Also, the assignment test is interesting, even with your rewording. The barrier is in the sequential part of the topic. In something like proofs, which is the closest I remember getting in high school to logic, those statements are simply invalid together, because there is no time domain. If `a` is 10, it is 10 throughout the entire construct. Seeing `a` is `b` means that an impossible conclusion has been reached.
Finally, the last point is, well, curious. How many people decide to go into aerospace engineering without ever having engineered an airframe? I'd guess the vast majority. Requiring prior exposure to succeed in a degree is an oddity, so what is is about CS education that causes this?
pbhjpbhj's point still stands -- the question is "supremely facile" once you get past matters of syntax. For example, most third graders could solve the problem when you make the time indexing explicit:
a(1) = 10 and b(1) is undefined.
a(2) = a(1) and b(2) = 20.
b(3) = b(2) and a(3) = b(3).
What is the value of a(3) and b(3)?
We can go a step further for students still struggling by associating to each variable at each time step a fresh variable (bonus: when they see SSA it'll be a breeze): Q = 10
W is undefined
R = Q
T = 20
Y = T
U = Y
What are the values of Y and U?
I've had students for whom even this didn't work, so I definitely don't believe "everyone can code". But still, if 30 - 60% of your students can't solve this problem, then there's something very wrong with the way the course is being managed, because I don't even get close to that percentage with sixth graders. Of course, I take the time to explain in excruciating detail what the symbols mean.So if I had to bet, it means that no one is sitting down and taking the time to help students get up to speed on the meaning of the syntax for this huge engineered system that was just thrown at them. Which is a real shame, because having these sorts of difficulties early in an intro course is, IME, completely uncorrelated with how the student will do throughout the rest of the curriculum.
You see the same thing when tutoring for early mathematics courses -- most students in the bottom of the distribution are having difficulty because some historical-cruft syntax is presented and not properly explained in lecture. Unsurprisingly, if no one bothers to explain what the hell the symbols mean, three more weeks of using the symbols to do more complicated stuff isn't particularly useful. So lack of movement among the groups isn't surprising, but reading off from that anything other than lack of sufficiently differentiated instruction is a fool's errand.
> Requiring prior exposure to succeed in a degree is an oddity
1. This is obviously not true for any of the natural sciences or for mathematics. It's also not true for English -- students have already done a lot of reading and essay writing by the time they get to college. Maybe it's a little more true for engineering fields, but at least there students are expected to have some background in math and physics. Oh, and also, typically take some university-level science and math alongside or prior to their serious engineering courses.
2. Requiring the mastery of large engineered systems during the first week or day of a course is also an extreme oddity.
On the second point, however, I still have some dispute. In maths or natural sciences, are you really expecting prior exposure to the subject matter? Or are you expecting a foundation upon which to build further? [1] I think the latter is a more appropriate statement. However, in CS, I feel it's more the former. "You must have experience programming, so that we can teach you how to properly program." If someone already knows how to program, what are they doing in a CS program other than getting a piece of paper that certifies their knowledge? Indeed, this is the argument you see regarding drop-outs or "equivalent experience" in lieu of degrees.
This is why I argue that we should instead find those fundamental building blocks and teach those instead. Basically, extract programming from the domain of computers, and figure out how to teach that. Then learning programming is about how those concepts apply to the domain of computers, much like how aerospace engineering is about learning how physics applies to airframes. [2]
[0] http://docs.racket-lang.org/r6rs/r6rs-std/r6rs-Z-H-2.html#no...
[1] It doesn't help that something like "math" is really more of an umbrella term for a large number of fields across different domains.
[2] This is, I'm sure, a huge simplification. Hopefully you can see the intent of my point and overlook the crude analogy.
I could get on board with teaching mathematical logic or combinatorics and discrete mathematics, for example. But "generalized sequential logic and reasoning" is hard for me to get too excited about because it's not a particularly useful concept outside of understanding and using imperative models of computation.
And if the only substantial motivation for teaching something is its application to some particular useful skill (programming in an imperative language), why not just teach that skill?
http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-...
But I think it's what spurred all the interest into the "bimodal hypothesis" that the current work explores.
:-)
:-)
Efficient computing machines are an important invention. Probably one of the most important inventions of the 20th century. The fundamental principles of computation are deep mathematical discoveries. Teaching some programming isn't an unreasonable way to teach about computation.
I was asked to tutor a first year engineering student in programming as she was failing. I ended up spending most of the time helping her conceptualize the problem and breaking it down into steps. Once she learnt that, she could manage the syntax aspects of C++. She ended up with a grade in the 60s which isn't bad considering she had a grade in the low 40s after the midterm.
When I was a TA for thermodynamics, I noticed that we would get a bimodal distribution on the midterm exam. Thermodynamics isn't hard once you understand it. We'd get the people who didn't understand with grades in the 40s, but the people who did had grades in the 70s and 80s. The prof said that was pretty common. The objective was to get as many people from the lower curve to the upper curve by the end of the term. You'd typically have around 3 to 5 of a class of 80 fail by the end. Those were the people who just didn't get it. I'm sure that thermo is one of many courses like this.
At the high school level, I remember taking a lot of required BS courses in high school, including public speaking, cooking/child care, a business course, and PE. No one suggested gutting core areas to make room for CS. Or at least, I didn't.
At the uni level I really don't think this would add significant overhead. Take your N sections of intro and switch one or more to intro-intro. Then get other departments to allow either one to fulfill a CS breadth requirement. Students who start with intro-intro can stuff an extra CS course in at some point after the intro sequence bottle neck.
This was at the university level. The problem is that my engineering department has a hard time fitting in courses. If you need an additional CS course that's one course covering something else that doesn't get included. We already merged our separate probability and statistics courses into a single course to make room for more intro materials.
For accreditation, all of our courses are broken down into having some of: Math, Intro Science, Engineering Science, and Engineering Design (and possibly none of these). You need a set amount in each category to get accreditation. Other departments have the same requirements, but their programs are designed to meet it. My department lets the student decide most of their upper year courses from across the university. So, if you decide to take a bunch of CS courses, you'll miss out and need to make it up on other courses. By the end, you need more Engineering Science and Engineering Design which isn't hard to do if you have mostly engineering courses, but pure CS courses basically give you nothing on these.
Until you actually participate in these kinds of discussions you don't know how carefully the overall curriculum is planned. Students going through my program have had a number of excellent suggestions, but it's hard to make changes and still meet all the requirements.
My department used to have more courses per term. Originally, there was 7 a term (I think), then there were 6. They've since moved to 5. That means you get 40 courses instead of 48 or 56.