3 ms·
The issue is that no one in CS seems to care that "Notation in any field is a barrier to entry". Almost all CS Ed research presently focuses on the problem-solv
by tsumnia 6y ago
The issue is that no one in CS seems to care that "Notation in any field is a barrier to entry". Almost all CS Ed research presently focuses on the problem-solving skill of CS rather than the technical literacy. There is almost no interest from educators to train this literacy despite work from myself [1] and others [2] saying that explicitly training these skills improves student performance.
The issue, in my opinion, is that notation and technical literacy are skills that students are "expected" to pick up through proxy. They do problem-solving problems, so they are getting experience coding. But the issue with this is that since novices are struggling with notation/syntax, they are juggling problem-solving issues (logic errors) and technical issues (syntax errors).
[1] https://dl.acm.org/doi/pdf/10.1145/3373165.3373177 https://dl.acm.org/doi/pdf/10.1145/3373165.3373177
[2] https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=8995&context=etd https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=8...
- klank 6y agoIs part of this due to an academic vs. professional dichotomy? i.e. most CS undergrads are CS undergrads to become professional developers, while most CS undergrad courses are taught with an eye towards further graduate/academic work?
- tsumnia 6y agoI wouldn't say so; I've taught for a community college, teaching college, and R1 and while there are differences, it seems to be a consistent issue across the board. While there are clearly individuals more interested in graduate work, there are groups with a primary goal of preparing students for industry.
- jimbob45 6y agoNo one seems to care? What is Python if not a referendum on unclear keywords and whitespacing?
- tsumnia 6y agoSorry, I mean to say in the CS Education domain.
- sidlls 6y agoIn physics, at least 20-some years ago when I was in academia, the notation of our common language (math) was simply part of the exposition when teaching new material to students. Maybe I had exceptions as instructors, but I carried their methods of presenting new notation into my classroom when I taught. Every field develops jargon and writing shorthand. It doesn’t have to be an artificial barrier to entry, and it’s a bit weird to me that this seems to be the case in programming.
- tsumnia 6y agoI don't think its so much the introduction of the notation, but rather the lack of practice in ensuring the learning of the notation. The analogies I've used in the past come from music and martial arts. In music, when you are first trying to learn an instrument, you aren't also being tested on music theory or creating brand new musical scores. You are focusing solely on being able to smoothly transition between keystrokes. Similarly, martial arts often see a high attrition rate. This has a number a reasons, but one that can be addressed is forcing novices to spar with more advanced students way too early. I know the Gracie Jiu-Jitsu schools shifted away from letting new students spar until they've trained for at least 6 months specifically because they didn't want students to show up, get destroyed, and quit out of frustration. Sort of my point is that the jargon and notation shouldn't simply be introduced and expected to be assimilated without explicit practice that is not confounded with additional problem-solving skills. Those can still be another practice activity, but students should be given the opportunity to just practice the skill without it.
- sidlls 6y agoYes, exactly. It is hard for me to imagine a physics instructor at any level introducing new mathematical techniques and more or less leaving the student on his or her own to decipher the runes required. The important part is the physics and the relationships of the quantities; not how they're represented on paper. It's kind of sad that CS doesn't seem to have a similar view.
- ywei3410 6y agoThat's really interesting - I enjoyed the section on transfer learning. Are there any screenshots of Phanon without having to sign-up to the Utah website? Do you think that reducing the amount of syntax-errors via a powerful structured-editor would help reduce the syntax burden?
- tsumnia 6y agoIts not a screenshot, but the Utah team posted this video for ICER [1] (with timestamp). I'm not apart of their team, so that's the best I can offer. > Do you think that reducing the amount of syntax-errors via a powerful structured-editor would help reduce the syntax burden? Truthfully, no. It would resolve syntax errors for sure, but I think there's something inherit to actually interacting and fixing mistakes that can't be replicated with technology. If you think about learning a second language, having an automatic translator will help you speak to other people, but you would not actually know the language. Not attempting to invoke Turing's Chinese Room, but rather there is a educational need to make mistakes, identify them, and resolve them that helps. [1] https://youtu.be/AdYMJ923Lys?t=90 https://youtu.be/AdYMJ923Lys?t=90
- jcorrington 6y agoWow, this really hits on something that's been rattling around my brain for years and has come to the forefront in the last week. In most disciplines to achieve mastery you generally focus on technical mastery first; drills, copying the works of the greats, stuff like that, before moving on to find your own "style" and making new creative works. I think a lot of the wisdom of the past about how to excel espoused the virtues of first being able to copy the works of the greats in your field. Yet, we think programming is somehow so different, that people should be able to make new creative works (ie: problem solving) at the same time as they're still trying to get a handle on the techniques. Being in the industry for 15 years has shown me there are a lot of really great problem solvers who are terrible at programming, despite having done it sometimes much longer than I have. There's one consistent distinction I generally see. The ones who can code fluently, for whom code just roles off their fingers, all started programming well before a CS program, maybe even back to middle school or earlier. And I don't believe it's that programming education is that great for the younger age groups (often it's non existent formally), but they have one key advantage. For the most part, they learn to program without the distraction of having to learn CS theory. Not so different from how a musician would likely first learn some simple scales, chords, and songs without any theory. For the unfortunate ones entering a CS program having written little or no code, they're bombarded with very difficulty CS theory and having to learn programming at the same time. I think we'd have both better programmers and better computer scientists if the education system did a better job separating the two. Thanks for linking your research, I'm going to give it a read soon. Is there a way I can get in touch? I'd love to discuss these ideas with you further and learn more about your research?.
- tsumnia 6y agoSure! My research bio is at [1]. And I definitely agree there's a disconnect between how younger individuals learn CS and college-level CS. Often those younger individuals could be seen as "automatic A's" because they've already overcame that first syntax hurdle. My current research is on exploring different exercise "types" with the hope of building a practice recommendation system that can identify which complexity a student should practice next - a typing or coding exercise, or something in between (Parson's Puzzles or Output Prediction, etc.) [1] https://research.csc.ncsu.edu/arglab/people/agaweda.html https://research.csc.ncsu.edu/arglab/people/agaweda.html