Posts tagged ‘computing education research’

Parsons Problems have same Learning Gains as Writing or Fixing code, in less time: Koli Calling 2017 Preview

On Saturday, Barbara Ericson will be presenting at Koli Calling her paper (with Lauren Margulieux and Jeff Rick), “Solving Parsons Problems Versus Fixing and Writing Code.”

The basic design of her experiment is pretty simple.  Everybody gets a pretest where they answer multiple-choiced questions, write some code, fix some code, and solve some Parsons problems.  (I’ve written about Parsons Problems here before.)

Then there are three instructional treatments with three different kinds of problem-solving practice:

  • One group gets Parsons Problems with distractors in them — blocks that should not be dragged into the solution.
  • One group gets the same code to fix — same code as in the Parsons Problems but all the distractors are there.  They have to fix the broken code in the distractor to get to the same code as the correct block in the Parsons.
  • One group gets to write the code to solve the same problem.

Then they take an isomorphic (same basic problems with context and constants changed) post-test, go away, and come back one week later for a retention test (which is isomorphic to both the pretest and the first posttest: multiple choice questions, Parsons, fix code, write code).  So we have students who study with Parsons Problems getting tested by writing and fixing code.

Here’s the bottom line from their abstract: “We found that solving two-dimensional Parsons problems with distractors took significantly less time than fixing code with errors or than writing the equivalent code. Additionally, there was no statistically significant difference in the learning performance, or in student retention of the knowledge one week later.”

That’s it. It’s simple but profound.  Below is the timing table from the paper. The Parsons Problems took effort, but always less time — sometimes they took only half the time of fixing or writing code, and other times it was only a few percentage less. But it was always less.

One takeaway idea is: If Parsons leads to the same learning in less time, why wouldn’t every teacher use more Parsons problems?  A second one that we’ve been thinking alot about is: Can we provide more Parsons problems so that in the same amount of time that students were writing code, they actually learn more? Efficiency matters, as Elizabeth Patitsas’s work suggests — more efficient learning may mean less belief in Geek Gene by CS teachers.

Cursor_and_ParsonsVsFixAndWrite-Final_pdf__page_8_of_10_

November 17, 2017 at 7:00 am 6 comments

Open Research Questions in Computing Education, 2017 Edition

When I last taught the Computing Education Research question class in 2015, we generated a list of open research questions (see post here).  We’ve got even more students this time in the class, so our list of questions is even longer.  We tried to cluster them, so similar questions should be near each other

.

Open Research Questions

What areas/findings of CS education research transfer to online learning? What doesn’t work the same?

Would more students pursue CS if it was incorporated into other introductory classes (different domains)?

Would more collaboration in two CS classes help reduce the defensive climate?

Do certain spoken languages allow for more effective learning of computing? If so, which ones?

Why don’t girls/minorities enter CS classes even if offered at their K12/undergrad school?

In underrepresented communities, is CS education a priority? If not, why not?

Does learning computing earlier quicken abstract reasoning?

How can you tell if a middle-schooler is learning computational thinking? What is computational thinking, operationally?

How can we get the attrition rate to decrease in CS education? Do we offer fewer jobs in industry? Force more people to teach CS? How do retain CS teachers?

Would teaching testing strategies from CS1 increase code writing skills?

Would undergrads be better programmers if they used weakly-typed languages before using strongly-typed languages?

Would students be better programmers if they learned ML or R first? Or if they learned to diagram programs first?

Can short informal CS Ed interventions (e.g., in museums, public spaces, etc.) have any effect on CS learning and/or self-efficacy and/or attitudes towards computing?

How can teach undergraduate students how to better understand documentation? Should we explore creating language documentation specific to intro classes?

How does learning functional vs. procedural programming first effect development of computational literacy?

How can we increase diversity in online CS education?

What kind of Community of Learners gravitates towards online education?

How can we make informal computational learning accessible to a wide audience?

Is it a positive or negative thing to have different forms of education for different communities within CS?

Would a computing course focused on creative activities have better recruitment/retention of diverse students?

Does physical computing engage students in a different way than traditional programming?

How do computational scientists think about code differently than computer scientists?

Can we teach computing to an elderly community of learners?

Would more diversity in Maker and Tinkerer spaces increase the diversity in CS?

November 3, 2017 at 6:00 am 5 comments

Learning Programming at Scale: Philip Guo’s research

I love these kinds of blog posts.  Philip Guo summarizes the last three years of his research in the post linked below.  I love it because it’s so important and interesting (especially for students trying to understand a field) to get a broad explanation of how a set of papers relate and what they mean.  Blog posts may be our best medium for presenting this kind of overview — books take too long (e.g., I did a book to do an overview of 10-15 years of work, but it may not be worth the effort for a shorter time frame), and few conferences or journals will publish this kind of introspection.

My research over the past three years centers on a term that I coined in 2015 called learning programming at scale. It spans the academic fields of human-computer interaction, online learning, and computing education.

Decades of prior research have worked to improve how computer programming is taught in traditional K-12 and university classrooms, but the vast majority of people around the world—children in low-income areas, working adults with full-time jobs, the fast-growing population of older adults, and millions in developing countries—do not have access to high-quality classroom learning environments. Thus, the central question that drives my research is: How can we better understand the millions of people from diverse backgrounds who are now learning programming online and then design scalable software to support their learning goals? To address this question, I study learners using both quantitative and qualitative research methods and also build new kinds of interactive learning systems.

Source: Learning Programming at Scale | blog@CACM | Communications of the ACM

September 11, 2017 at 7:00 am Leave a comment

The Role of Emotion in Computing Education, and Computing Education in Primary School: ICER 2017 Recap

I wrote my Blog@CACM post in August about the two ICER 2017 paper awards:

  • Danielsiek et al’s development of a new test of student self-efficacy in algorithms classes;
  • Rich et al.’s trajectories of K-5 CS learning, which constitute an important new set of theories about how young students learn computing.

Rich et al.’s paper is particularly significant to me because it has me re-thinking my beliefs about elementary school computer science. I have expressed significant doubt about teaching computer science in early primary grades — it’s expensive, there are even more teachers to prepare than in secondary schools, and it’s not clear that it does any longterm good. If a third grader learns something about Scratch, will they have learned something that they can use later in high school? Katie Rich presented not just trajectories but Big Ideas. Like Big Ideas for sequential programming include precision and ordering. It’s certainly plausible that a third grader who learns that precision and ordering in programs matters, might still remember that years later. I can believe that Big Ideas might transfer (at least, within computing) over years.

I was struck by a recurring theme of emotion in the papers at ICER 2017. We have certainly had years where cognition has been a critical discussion, or objects, or programming languages, or student’s process. This year, I noticed that many of these papers were thinking about beliefs and feelings.

I find this set of papers interesting for highlight an important research question: What’s the most significant issue influencing student success or withdrawal from computer science? Is it the programming language they use (blocks vs text, anyone?), the kind of error messages they see, the context in which the instruction is situated, or whether they use pair programming? Or is the most significant issue what the students believe about what they’re doing? And maybe all of those other issues (from blocks to pairs) are really just inputs to the function of student belief?

(Be sure to check out Andy Ko’s summary of ICER 2017.)

September 1, 2017 at 7:00 am 1 comment

Teachers are not the same as students, and the role of tracing: ICER 2017 Preview

The International Computing Education Research conference starts today at the University of Washington in Tacoma. You can find the conference schedule here, and all the proceedings in the ACM Digital Library here. In past years, all the papers have been free for the first couple weeks after the conference, so grab them while they are outside the paywall.

Yesterday was the Doctoral Consortium, which had a significant Georgia Tech presence. My colleague Betsy DiSalvo was one of the discussants. Two of my PhD students were participants:

We have two research papers being presented at ICER this year. Miranda Parker and Kantwon Rogers will be presenting Students and Teachers Use An Online AP CS Principles EBook Differently: Teacher Behavior Consistent with Expert Learners (see paper here) which is from Miranda C. Parker, Kantwon Rogers, Barbara J. Ericson, and me. Miranda and Kantwon studied the ebooks that we've been creating for AP CSP teachers and students (see links here). They're asking a big question: "Can we develop one set of material for both high school teachers and students, or do they need different kinds of materials?" First, they showed that there was statistically significantly different behaviors between teachers and students (e.g. different number of interactions with different types of activities). Then, they tried to explain why there were differences.

We develop a model of teachers as expert learners (e.g., they know more knowledge so they can create more linkages, they know how to learn, they know better how to monitor their learning) and high school students as more novice learners. They dig into the log file data to find evidence consistent with that explanation. For example, students repeatedly try to solve Parsons problems long after they are likely to get it right and learn from it, while teachers move along when they get stuck. Students are more likely to run code and then run it again (with no edits in between) than teachers. At the end of the paper, they offer design suggestions based on this model for how we might develop learning materials designed explicitly for teachers vs. students.

Katie Cunningham will be presenting Using Tracing and Sketching to Solve Programming Problems: Replicating and Extending an Analysis of What Students Draw (see paper here) which is from Kathryn Cunningham, Sarah Blanchard, Barbara Ericson, and me. The big question here is: "Of what use is paper-and-pen based sketching/tracing for CS students?" Several years ago, the Leeds' Working Group (at ITiCSE 2004) did a multi-national study of how students solved complicated problems with iteration, and they collected the students' scrap paper. (You can find a copy of the paper here.) They found (not surprisingly) that students who traced code were far more likely to get the problems right. Barb was doing an experiment for her study of Parsons Problems, and gave scrap paper to students, which Katie and Sarah analyzed.

First, they replicate the Leeds' Working Group study. Those who trace do better on problems where they have to predict the behavior of the code. Already, it's a good result. But then, Katie and Sarah go further. For example, they find it's not always true. If a problem is pretty easy, those who trace are actually more likely to get it wrong, so the correlation goes the other way. And those who start to trace but then give up are even more likely to get it wrong than those who never traced at all.

They also start to ask a tantalizing question: Where did these tracing methods come from? A method is only useful if it gets used — what leads to use? Katie interviewed the two teachers of the class (each taught about half of the 100+ students in the study). Both teachers did tracing in class. Teacher A's method gets used by some students. Teacher B's method gets used by no students! Instead, some students use the method taught by the head Teaching Assistant. Why do some students pick up a tracing method, and why do they adopt the one that they do? Because it's easier to remember? Because it's more likely to lead to a right answer? Because they trust the person who taught it? More to explore on that one.

August 18, 2017 at 7:00 am Leave a comment

Call for Papers for 2nd Blocks and Beyond Workshop

Call for Participation

Blocks and Beyond 2:
2nd Workshop on Lessons and Directions for
First Programming Environments

http://cs.wellesley.edu/blocksandbeyond

October 9-10, 2017, Raleigh, NC, USA

A satellite workshop of the 2017 IEEE Symposium
on Visual Languages and Human-Centric Computing (VL/HCC)

https://sites.google.com/site/vlhcc2017/

Call for Participation

Scope and Goals

Blocks programming environments represent program syntax trees as compositions of visual blocks. They are an increasingly popular way to introduce programming and computational thinking; tens of millions of people have used tools like Scratch, Blockly, App Inventor, Snap!, Pencil Code, Alice/Looking Glass, AgentSheets/AgentCubes, and Code.org’s curricula. But blocks programming is not just for beginners; environments like GP and domain-specific blocks languages are targeted at hobbyists, scientists. and other casual programmers.

Capitalizing on the energy and enthusiasm from the 1st Blocks and Beyond Workshop in Atlanta in 2015, this workshop aims to continue studying the usability, effectiveness, and generalizability of affordances of these environments and their associated pedagogies. The workshop will bring together educators and researchers with experience in blocks languages, as well as members of the broader VL/HCC community who wish to examine this area more deeply. We seek participants with diverse expertise, including, but not limited to: design of programming environments, instruction with these environments, the learning sciences, data analytics, usability, and more.

The workshop will be a generative discussion that sets the stage for future work and collaboration. It will include participant presentations and demonstrations that frame the discussion, followed by reflection on the state of the field and smaller working-group discussion and brainstorming sessions.

Suggested Topics for Discussion

·  Who uses blocks programming environments and why?

·  Which features of blocks environments help or hinder users? How do we know? Which of these features are worth incorporating into more traditional IDEs? What helpful features are missing?

·  How can blocks environments and associated curricular materials be made more accessible to everyone, especially those with disabilities?

·  Can blocks programming appeal to a wider range of interests (e.g., by allowing connections to different types of devices, web services, data sources, etc.)?

·  What are the best ways to introduce programming to novices and to support their progression towards mastery? Do these approaches differ for for learners of computing basics and for makers?

·  What are the conceptual and practical hurdles encountered by novice users of blocks languages when they face the transition to text languages and traditional programming communities? What can be done to reduce these hurdles?

·  How can we best harness online communities to support growth through teaching, motivating, andproviding inspiration and feedback?

·  What roles should collaboration play in blocks programming? How can environments support that collaboration?

·  In these environments, what data can be collected, and how can that data be analyzed to determine answers to questions like those above? How can we use data to answer larger scale questions about early experiences with programming?

·  What are the lessons learned (both positive and negative) from creating first programming environments that can be shared with future environment designers?

Submission

We invite two kinds of submissions:

1.       A 1 to 4 page position statement describing an idea or research question related to the design, teaching, or study of blocks programming environments.

2.       A paper (up to 8 pages) describing previously unpublished results involving the design, study, or pedagogy of blocks programming environments.

All submissions must be made as PDF files to the Easy Chair Blocks and Beyond workshop submission site.

As with the Proceedings of the 1st Blocks and Beyond Workshop, we plan to publish the proceedings of the 2nd Workshop with the IEEE. Please use an IEEE Conference template to format your submission.

Important Dates

·  19 Jul 2017: Submissions due (due by end of day, anytime on Earth)

·  16 Aug 2017: Author notification

·  30 Aug 2017: Camera ready copies due

·  9-10 Oct 2017: Workshop in Raleigh

June 23, 2017 at 7:00 am Leave a comment

Older Adults Learning Computer Programming: Motivations, Frustrations, and Design Opportunities

Great new Blog@CACM post by Philip Guo summarizing his recent CHI publication — how do people over 60 learn to program?  I’m so excited that Philip is exploring these issues. I’m interested in these issues, too, since I wrote about the challenges of learning as an adult and about the possibility of CS meet-ups for adult learners.  Philip is offering data, which I very much appreciate.

Why study older adults in particular? Because this population is already significant and also quickly growing as we all (hopefully!) continue to live longer in the coming decades. The United Nations estimates that by 2030, 25% of North Americans and Europeans will be over 60 years old, and 16% of the worldwide population will be over 60. There has been extensive research on how older adults consume technology, and some studies of how they curate and produce digital content such as blogs and personal photo collections. But so far nobody has yet studied how older adults learn to produce new technologies via computer programming.

Thus, to discover older adults’ motivations and frustrations when learning to code, I designed a 10-question online survey that asked about their employment status (e.g., working, semi-retired, retired), occupation, why they are learning, what resources they use to learn, and what has been the most frustrating part of their learning experience thus far.

Source: Older Adults Learning Computer Programming: Motivations, Frustrations, and Design Opportunities | blog@CACM | Communications of the ACM

June 12, 2017 at 7:00 am 1 comment

Older Posts


Recent Posts

November 2017
M T W T F S S
« Oct    
 12345
6789101112
13141516171819
20212223242526
27282930  

Feeds

Blog Stats

  • 1,452,090 hits

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 5,177 other followers

CS Teaching Tips