Posts tagged ‘computing education research’
Source of the “Geek Gene”? Teacher beliefs: Reading on Lijun Ni, Learning from Helenrose Fives on teacher self-efficacy
I discovered the below quoted post when I was looking up a paper by my former student, Lijun Ni. It’s nice to see her work getting recognized and reviewed! I talked a lot about her work when I was talking to PhD students at the University of Oldenburg program — Lijun has studied the beliefs of CS teachers, and that’s super important.
One of the other international guests at the Oldenburg program I attended last month (see post here) was Helenrose Fives who has literally written the book on teacher beliefs (see Amazon reference). Several of the PhD students who presented their research talked about student teachers having lower self-efficacy after actually being in the classroom, less commitment to ideals like inquiry learning, and less belief that students can learn. Helenrose said that that’s really quite common. Teachers have a high level of self-efficacy (“I can teach using novel approaches that will really help students learn!”) before they enter the classroom, and that sense of self-efficacy falls off a cliff once they face the reality of the classroom. The self-efficacy rises over time (up and down, but mostly up) but never reaches the optimism of before teachers enter the classroom.
I talked to Helenrose about what her work means for University CS teachers. In general, the work she describes is about school teachers, not faculty. She agreed that it’s possible for University CS teachers to have high self-efficacy even if they are not successful teachers, because University teachers define self-efficacy differently than school teachers. School teachers are responsible for student learning. They know individual students. They actually know if they are successful in their teaching or not (in terms of student learning and engagement). University teachers tend to have larger classes, and they tend to teach via lecture. They usually have little knowledge of individual student learning and engagement. Their sense of self-efficacy may arise from their ability to succeed at their task, “I can give great lectures. (Almost nobody falls asleep.) I can manage huge classes.” Where they do have knowledge of learning and evidence of ineffective teaching, they may simply decide that it’s the student’s fault. Perhaps this is where the Geek Gene is born.
Here’s a hypothesis: If a University teacher has high self-efficacy (great confidence in his or her teaching ability) and sees evidence of students not learning, it’s rational for that teacher to believe that the problem lies with the students and that the problem is innate — beyond the ability of the teacher to improve it.
In the first study, Ni interviewed teachers about their identity in order to establish what strengths and weaknesses are common in high school computer science teachers. She found that the teaching identity of computer science teachers is largely underdeveloped compared to teachers in other fields, and that often computer science teachers prefer to identify as a math teacher or a business teacher, rather than a computer science teacher.
Further, she found that high school computer science teachers generally do not have any sort of teaching support community to turn to, because they are often the only computer science teacher at their school.
All of these problems combine to keep computer science teachers from developing a strong teaching identity centered in the computer science field. Instead, we have teachers with low commitment levels to the field training our next generation of programmers in basic computing skills that are generally unrelated to the field of computer science itself.
I had the honor to serve on Tom Park’s dissertation committee and got to see this work unfold. It’s important to do. Computer scientists are happy to tell you that “HTML is not really programming,” and that’s true. But what computing education researchers need to realize is that HTML is a formal, computing-interpreted notation — probably the first one that most computing students ever face. Understanding what works and doesn’t there is important to understanding what’s hard about formal computing representations at all, versus what’s complicated because it’s programming. For example, over 50% of the knowledge-based errors that were observed in the study were never resolved. That’s the definition of a hard problem that’s worth understanding to improve education. It’s also important to consider — are those also learning difficulties that we see in programming?
In the end, the number of errors under the three aforementioned categories broke down as follows:
70.9% of all errors were skill-based errors.
16.9% were rule-based errors.
12.1% were knowledge-based errors.
As mentioned, most of the errors were resolved during the task completion process, but some were not, and they broke down like this:
4.3% of all skill-based errors were unresolved.
39.6% of rule-based errors were unresolved.
52.1% of knowledge-based errors were unresolved.
Want to give a lightning talk or present a poster in Omaha, August 10-12 to spark discussion or discover possible collaborations? Keep reading!
Lightning Talk Application Deadline: June 15, 2014 (submission details below)
ICER 2015 — International Computing Education Research Conference
University of Nebraska, Omaha
August 10-12, 2015
What is a Lightning Talk?
Lightning Talks are strictly timed 3 minute presentations intended to further expand the ICER community and spark discussion among conference participants. The intent is for these talks to provide a venue in support of new ideas and newcomers to our community. Lightning Talks are a great way to get early feedback on a work in progress, to demo a new tool or technique, and to find potential collaborators at other institutions.
What is a Poster?
Posters are a new way for ICER attendees to present early results, gain feedback from conference attendees, find collaborators on a topic, and/or spark discussion among conference participants. The intent is for these posters is similar to lightning talks in that they provide a venue in support of new ideas and newcomers to our community.
Can I do both – give a Lightning Talk and have a Poster?
Absolutely! New this year, Lightning Talk presenters may elect to present a poster in conjunction with their lightning talk to provide additional information to curious parties and help foster post-lightning talk discussion.
Note: Work already being presented at ICER (i.e., accepted papers, doctoral consortium submissions) is ineligible for the lightning talks or poster sessions.
Submissions for consideration as lightning talks should use the provided MS Word template and are limited to a maximum of 300 words. Abstracts should be submitted no later than June 15 to Leo Porter at firstname.lastname@example.org for consideration. The template can be found at:
Are there additional opportunities to receive feedback on a work in progress?
If you are interested in an interactive feedback session after ICER, you may also want to check out the Works in Progress Workshop:
Please let me know if you have any questions!
Assistant Teaching Professor, Computer Science
University of California, San Diego
I’m leaving May 24 for a two week trip to Germany. Both one week parts are interesting and worth talking about here. I’ve been reflecting on my own thinking on the piece between, and how it relates to computing education themes, too.
I’m attending a seminar at Schloss Dagstuhl on Human-Centric Development of Software Tools (see seminar page here). Two of the seminar leaders are Shriram Krishnamurthi of Bootstrap fame who is a frequent visitor and even a guest blogger here (see post here) and Andy Ko whose seminal work with Michael Lee on Gidget has been mentioned here several times (for example here). I’ve only been to Dagstuhl once before at the live-coding seminar (see description here) which was fantastic and has influenced my thinking literally years later. The seminar next week has me in the relative-outsider role that I was at the live-coding seminar. Most of the researchers coming to this event are programming language and software engineering researchers. Only a handful of us are social scientists or education researchers.
The Dagstuhl seminar ends Thursday after lunch. Saturday night, I’m to meet up with a group in Oldenburg Germany and then head up Sunday to Stadland (near the North Sea) for a workshop where I will be advising STEM Education PhD students. I don’t have a web link to the workshop, but I do have a page about the program I’ll be participating in — see here. My only contact there is Ira Diethelm, whom I’ve met several times and saw most recently at WIPSCE 2014 in Berlin (see trip report here). I really don’t know what to expect. Through the ICER DC and WIPSCE, I’ve been impressed by the Computing Education PhD students I’ve met in Germany, so I look forward to an interesting time. I come back home on Friday June 5 from Bremen.
There’s a couple day gap between the two events, from Thursday noon to Saturday evening. I got a bunch of advice on what to do on holiday. Shriram gave me the excellent advice of taking a boat cruise partway north, stopping at cities along the way, and then finishing up with a train on Saturday. Others suggested that I go to Cologne, Bremen, Luxembourg, or even Brussels.
I’ve decided to take a taxi to Trier from Dagstuhl, tour around there for a couple days, then take a seven hour train ride north on Saturday. Trier looks really interesting (see Tripadvisor page), though probably not as cool as a boat ride.
Why did I take the safer route?
The science writer, Kayt Sukel, was a once student of mine at Georgia Tech — we even have a pub together. I am so pleased to see the attention she’s received for her book Dirty Minds/This is Your Brain on Sex. She has a new book coming out on risk, and that’s had me thinking more about the role of risk in computing education.
In my research group, we often refer to Eccles model of academic achievement and decision making (1983), pictured below. It describes how students’ academic decisions consider issues like gender roles and stereotypes (e.g., do people who are like me do this?), expectation for success (e.g., can I succeed at this?), and the utility function (e.g., will this academic choice be fun? useful? money-making?). It’s a powerful model for thinking about why women and under-represented minorities don’t take computer science.
Eccles’ model doesn’t say much about risk. What happens if I don’t succeed? What do I need to do to reduce risk? How will I manage if I fail? How much am I willing to suffer/pay for reduced risk?
That’s certainly playing into my thinking about my in-between days in Germany. I don’t speak German. If I get into trouble in those in-between days, I know nobody I could call for help. I still have another week of a workshop with a keynote presentation after my couple days break. I’ve already booked a hotel in Trier. I plan on walking around and taking pictures, and then I will take a train (which I’ve already booked, with Shriram’s help) to Oldenburg on Saturday. A boat ride with hops into cities sounds terrific, but more difficult to plan with many more opportunities for error (e.g., lost luggage, pickpockets). That’s managing risk for me.
I hear issues of risk coming into students’ decision-making processes all the time, combined with the other factors included in Eccles’ model. My daughter is pursuing pre-med studies. She’s thinking like many other pre-med students, “What undergrad degree do I get now that will be useful even if I don’t get into med school?” She tried computer science for one semester, as Jeanette Wing recommended in her famous article on Computational Thinking: “One can major in computer science and go on to a career in medicine, law, business, politics, any type of science or engineering, and even the arts.” CS would clearly be a good fallback undergraduate degree. She was well-prepared for CS — she had passed the AP CS exam in high school, and was top of her engineering CS1 in MATLAB class. After one semester in CS for CS majors, my daughter hated it, especially the intense focus on enforced software development practices (e.g., losing points on homework for indenting with tabs rather than spaces) and the arrogant undergraduate teaching assistants. (She used more descriptive language.) Her class was particularly unfriendly to women and members of under-represented groups (a story I told here). She now rejects the CS classroom culture, the “defensive climate” (re: Barker and Garvin-Doxas). She never wants to take another CS course. The value of a CS degree in reducing risks on a pre-med path does not outweigh the costs of CS classes for her. She’s now pursuing psychology, which has a different risk/benefit calculation (i.e., a psychology undergraduate degree is not as valuable in the marketplace as a CS undergraduate degree), but has reduced costs compared to CS or biology.
Risk is certainly a factor when students are considering computer science. Students have expectations about potential costs, potential benefits, and about what could go wrong. I read it in my students’ comments after the Media Computation course. “The course was not what I expected! I was expecting it to be much harder.” “I took a light load this semester so that I’d be ready for this.” Sometimes, I’m quite sure, the risk calculation comes out against us, and we never see those students.
The blog will keep going while I’m gone — we’re queued up for weeks. I may not be able to respond much to comments in the meantime, though.
Hilary Dwyer is starting an effort to create a special interest group at the American Educational Research Association (AERA) just for computer science education. Please do complete her poll — especially if you are an AERA member. We need 75 signatures on the poll to be able to create the SIG.
I’ve been looking forward to seeing this article appear in CACM for over a year. Last January and May, I heard Sally Fincher give two talks about computing education research (CER), where she started by describing (failed) efforts to teach reading over the last hundred years. She created a compelling analogy. What educators were doing when they simplified the learning of reading seem analogous to our efforts today to simplify the learning of programming — but those efforts to teach simplified reading led to significant harm to the students. What harm are we doing to students when we teach programming in these new ways? She is not calling for an end to these efforts. Rather, she’s calling for research to figure out what we’re doing and to investigate the effects. She agreed to write up her story for Viewpoints, which is published this month in CACM. Thanks, Sally!
Other approaches believe it is more appropriate to use real syntax, but constrain the environment to a particular (attractive) problem domain so learners become fluent in a constrained space. Event-driven environments (such as Greenfoot) or scaffolded systems (like Processing.js) aim for the learner to develop an accurate mental model of what their code is doing, and ultimately transfer that to other environments. Although whether they actually do so remains unclear: we may be restricting things in the wrong way.
Still others hold that coding—howsoever approached—is insufficient for literacy and advocate a wider approach, taking in “computational thinking,” for instance as embedded in the framework of the “CS Principles”: Enduring Understandings, Learning Objectives, and Essential Knowledge.
What is resolutely held common with traditionally formulated literacy is that these approaches are unleashed on classrooms, often whole school districts, even into the curriculum of entire countries—with scant research or evaluation. And without carrying the teachers. If we are to teach computing in schools we should go properly equipped. Alongside the admirable energy being poured into creating curricular and associated classroom materials, we need an accompanying set of considered and detailed programs of research, to parallel those done for previous literacies.
The ICER 2015 Doctoral Consortium provides an opportunity for doctoral students studying computing education to explore and develop their research interests in a workshop environment with a panel of established researchers. We invite students to apply for this opportunity to share their work with students in a similar situation as well as senior researchers in the field.
Applicants to the Doctoral Consortium should have begun their research, but should not have completed it in its entirety. We want people who have questions to raise with their peers and the more senior mentors. Someone who is all-but-defended probably does not want to be raising any questions.
DC Co-Chairs for 2015:
Mark Guzdial, Georgia Institute of Technology
Anthony Robins, University of Otago, New Zealand
Contact us at: email@example.com
The DC has the following objectives:
- Provide a supportive setting for feedback on students’ research and research direction
- Offer each student comments and fresh perspectives on their work from researchers and students outside their own institution
- Promote the development of a supportive community of scholars
- Support a new generation of researchers with information and advice on research and academic career paths
- Contribute to the conference goals through interaction with other researchers and conference events
The DC will be held on Sunday, August 9 2015. Students at any stage of their doctoral studies are welcome to apply and attend. The number of participants is limited to 15. Applicants who are selected will receive a limited partial reimbursement of travel, accommodation and subsistence (i.e., food) expenses of $600 (USD).
- Wednesday 20th May – initial submission
- Monday 1st June – notification of acceptance
- Monday 15th June – camera ready copy due
You can find more information on applying at http://icer.hosting.acm.org/icer-2015/doctoral-consortium/