933 karma · joined August 12, 2013
Academic motivation is a force caused by a wide range of internal and external factors, which people experience in different quantities at different times. Sometimes, you are in a course simply because you are obligated to be there and you do well because you need it to accomplish a long-term goal. Sometimes, you are solving a course problem because you find it intellectually stimulating. Sometimes, you give up on a problem because you believe you cannot succeed. Sometimes, you are simply unmotivated because you are tired and don't want to deal with stuff anymore. The MUSIC model of academic motivation [1] suggests a number of factors involved in the process.
Of course, I don't want to sound entirely dismissive - I definitely see the value in ensuring students perceive the "need" to solve a problem, and it's undoubtedly fantastic for an instructor to create that perception. I just wanted to voice that there's more to motivation than just the one avenue, and that's not necessarily a bad thing.
I would compare this to asking, "Why don't software developers think about bugs?" They do, and they attempt to handle them, but it's almost impossible to solve all such problems in programs (tests) of non-trivial size.
"Self-taught all-around software-guy in his 20s. Just moved out to California. Passionate about software, psychology, self-sustaining systems, and business. Dabble in everything else (philosophy, go, reverse-engineering, painting, writing, chess, meditation, music, DVORAK). Preference for writing in fragments rather than sentences. ;)"
Obviously, philosophy is only worth attacking if you studied it formally.
"Self-taught all-around software-guy in his 20s. Just moved out to California. Passionate about software, psychology, self-sustaining systems, and business. Dabble in everything else (philosophy, go, reverse-engineering, painting, writing, chess, meditation, music, DVORAK). Preference for writing in fragments rather than sentences. ;)"
So, philosophy is only bad if you study it in school!
Learning Styles is mostly considered snake oil. Of course different students learn differently. Assessment is hard. Instructional Design. There's so much material out there, I wish people would learn more before asserting and speculating.
I suppose I should just be pleased that people are interested. But I hope many posters will be encouraged to look further into this subject and develop expertise as they develop their opinions.
Here's one potential resource: http://www.learningandteaching.info/
Let's you switch back and forth seamlessly as you learn. Among other features.
It's also interesting to compare Python and JavaScript. Holkner and Harland did a pair of papers about those two communities' usage of dynamic typing - JS people do type changes throughout the program execution, but after initialization the Python people follow the Aycock quote: "Giving people a dynamically-typed language does not mean that they write dynamically-typed programs." Languages have different characteristic programs, to some degree.
age, height, weight = person_data
Silly example for such a useful tool.For those wondering why I put my buzzwords in quotes, it's because I don't want to sound like I'm a huge proponent of either of them. CT is the term I use to describe how I teach my students about abstractions, algorithms, and some programming. DS is the term I use to describe how students learn all of that in the context of working with data related to their own majors. I'm not trying to claim some crazy paradigm shift, just that it's a great way to convince students that CS is useful to them.
As for profitability, I'd argue that stupid people with strong opinions and a need to vocalize them are advertisers favorite kind of people. They're probably surprisingly profitable.
[1] Don't assume I'm putting any of those on the same level as each other, just making a list of what I suspect are violatile items to some groups.
http://www.cs.colorado.edu/~ralex/papers/PDF/SIGCSE10-repenn...
However, from what I've read of work with younger learners, you'd be amazed at the level of complexity their code can reach. Just because you're young doesn't mean you can't write big complex programs. Of course, when they're older they'll look back on much of their work and say, "Oh it's so bad". But that's just what learning means.
As for "damaging" learners - banish the thought. Short of actively lying and gaslighting students, I've always found learners to be extremely robust. In fact, technology and context have relatively little impact on young students long-term compared to positive, excellent interactions with educators who know what they're doing. It's more important for students to have successful experiences that are fun and make them think, "Hey, this does stuff! Like, real stuff!" There are many nuances to that statement (gender is particularly fascinating), but I've found it's mostly true. Learning is all about constructing experiences on top of experiences, and your introductory experiences will always have degrees of artificiality and scaffolding. Understanding evolves with time, effort, and feedback.
We say that Abstracting an entity (the most vague word we've found, referring to people, places, things, events, and even other abstractions) causes you to lose details. That abstraction is contextualized to a stakeholder, since you have to have some criteria for deciding what details you keep and lose. An abstraction for a person would be different if it was for Facebook ("Name", "Age", "List of Friends") or for a doctor ("Name", "Age", "Sickness"). Abstraction is powerful because it lets us concretize real, vague things into something that a computer can understand and process ("Because computers are very stupid!").
I often discuss how an abstraction loses a lot of valuable data. One student was working with NFL games, representing them a set of properties like ("away team name", "home team name", "away team wins", "home team wins"). That representation ignores how many interceptions were made, the weather that day, the feelings that the crowd had, how much effort the players put into training - a lot of "humanist" data.
This article makes me wonder what goes through their minds. No one's complained about making these abstractions - they've never suggested we're ruining a game, a historical event, or whatever we're abstracting. But I think maybe we should encourage the students to think about what happens when you abstract something and what it means for the entity and not just the stakeholder.
The nine inhabitants of Bool -> Tri: https://gist.github.com/acbart/5d3fdfd8d363af26a59c
The eight inhabitants of Tri -> Bool: https://gist.github.com/acbart/c695355880a706a4ff59
Pedagogical note: If you're going to poise a question in an online presentation of material, try to have a solution (automatically checked or at least statically available). A huge part of learning is having the learner participate (which you did!) and then assessed.
[1] I got help from here, @tikhonj suggested this in another comment: http://chris-taylor.github.io/blog/2013/02/10/the-algebra-of...