Posts tagged ‘computing education research’
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/
Barb and I went to this last year, and it was terrific — diverse and high-quality.
Call for Papers and Participation:
We invite you to submit a paper, report, or poster for the 10th Workshop in Primary and Secondary Computing Education (WiPSCE 2015) and join us inLondon, United Kingdom, on November 9-11, 2015. WiPSCE aims at improving the exchange of research and practice relevant to teaching and learning in primary and secondary computing education, teacher training, and related research.
Important 2015 Dates
Submission deadline: Monday, June 1
Re-submission deadline: Monday, June 8
Notification of acceptance: Monday, July 27
Submission of revised manuscripts: Monday, September 15
Early Registration deadline: Monday, October 19
Original submissions in all areas related to primary and secondary computing education are invited in the following categories:
- Full paper (6–10 pages): expected to meet one of two categories – empirical research papers and philosophical research papers
- Work in progress (3-4 pages): unpublished original research in progress
- Practical report (4-6 pages): unpublished, original projects in the field of “primary and secondary computing education”
- Posters (2 page abstract)
- Learning: attitudes, beliefs, motivation, misconceptions, learning difficulties, student engagement with educational technology (e.g., visualization), conceptualization of computing
- Teaching: teaching approaches, teaching methods, teaching with educational technology
- Content: curricular aspects, learning standards, tools, educational approaches, context relevant teaching, assessment
- Institutional aspects: establishing and enhancing computing education, professional development
Special Theme:Computing? How young is too young?
For more information, please contact:
Judith Gal-Ezer: firstname.lastname@example.org
Sue Sentence: email@example.com
Jan Vahrenhold: firstname.lastname@example.org
UToronto TA’s and graduate student instructors on strike: Pay and teaching are inversely correlated in Universities today
The graduate student Teaching Assistants and Instructors at the University of Toronto are on strike. I wouldn’t normally be aware about graduate student labor disputes in other countries, but UToronto has an active CS Education research group and at least one (very) active CS Ed PhD student, Elizabeth Patitsas who was in the ICER Doctoral Consortium last year. The website on the strike (see link below and here) is interesting in describing the situation for Canadian PhD students, both what’s different than in the US (Toronto PhD students pay tuition — it isn’t waived for them) and what’s similar. I’ll bet that the fact 3.5% of the university budget pays for 65% of the teaching is just as true in the US. The Chronicle had an article recently titled Teach or Perish (see link here) with this claim (that I’m quite certain is true where I’m at, success is measured in terms of salary): “While teaching undergraduates is, normally, a large part of a professor’s job, success in our field is correlated with a professor’s ability to avoid teaching undergraduates.”
Graduate students in PhD programs continue to pay full tuition – almost $8,000 – even when they are not enrolled in courses. In return, graduate students receive the ‘privilege’ of underpaid work for the University, a library card, and meetings with supervisors. All comparable universities in North America offer post-residency fees or tuition wavers for graduate students finished with course work. The university rejected our proposals for similar provisions.
CUPE 3902 membership has been without a permanent contract for more than eight months, despite carrying out more than 65% of the teaching across the three campuses at the University of Toronto.
The university allocates a mere 3.5% of its $1.9 billion budget to CUPE 3902 workers, the vast majority of which comes from tuition and taxes.
via We Are UofT.
Starting from the students to build engaging computing courses for non-CS majors: Response to Goldweber and Walker
Michael Goldweber and Henry Walker responded to my blog posts (here in Blog@CACM and here in this blog) in the Inroad blog (see article here). My thanks to them for taking the time to respond to me. I found their comments especially valuable in helping to see where I was making assumptions about common values, goals, and understanding. It’s too easy in a blog to only get responses from people who share a common understanding (even if we violently disagree about values and goals). I found it helpful to get feedback from Dr. Goldweber and Dr. Walker with whom I don’t correspond regularly.
“Pedagogy” isn’t just “how to teach” for me. They argue that their articles are not about pedagogy but about what should be taught in a course that students might take to explore computer science. The page I linked to at the US Department of Education is about evidence-based education, not evidence-based pedagogy. The definition of pedagogy is “the discipline that deals with the theory and practice of education” (Wikipedia link). One meaning of pedagogy is the whole field of education, which is how I meant it in that piece (as in Pedagogy of the Oppressed.) What to teach is part of pedagogy. If we don’t use evidence for making decisions what to teach, we are practicing folk pedagogy.
My larger point was about the role of evidence rather than intuition. Whether we’re talking about how to teach or what to teach, I believe that we have to gather evidence (or in Paulo Freire’s terms, have a dialog with the students and stakeholders). Certainly, we want to gather evidence about the effectiveness of our teaching. We also need to gather evidence when designing education. My background is in education and HCI. For me, “Know thy users for they are not you” is a given in HCI, and “Student-centered” is a given in Education. Both saying suggest that we start with not-me: not the designer, not the teacher, not the domain expert. But for Dr. Walker, “The starting point is identifying the themes and Big Ideas, not pedagogy.”
The unspoken assumption behind my posts, which may not be shared with Dr. Walker and Dr. Goldweber, is that any CS course for non-CS majors (whether a service, elective, or exploratory course) should aim to increase interest in the field of CS, and especially, should be designed to attract and engage women and under-represented minorities in CS. If we are happy with just having the male white and Asian students that we typically attract now, then sure, Dr. Goldweber’s right — we can just do like Philosophy does and build the course based on what we think is important.
Dr. Walker is absolutely right — there is too little time in a course to fit in everything that we think is important about CS. Even if we leave programming out, there is still too much material. How do we decide which Big Ideas to include?
In my process, I start with the students. What are their life goals and desired careers? What’s needed from computing for them to be successful? What are their values? How can I show that computer science is relevant to those values? To choose among the ideas of computer science, we should use what the students need. To teach the ideas that students may not know they need, we should speak to their values.
I disagree with Dr. Goldweber on these points:
The design of a non-major’s course in computing, which is not a service course for some other department/program, should belong in the hands of the CS faculty. Students electing to explore a discipline take these courses. Surely, discipline experts are those who can best decide what to present from the discipline.
We can just design courses for non-CS majors based on our own experience and intuition. We shouldn’t be surprised, then, if we mostly attract white or Asian males and if we fail to engage diverse audiences. Since all three of us (Dr. Walker, Dr. Goldweber, and me) are white, male, CS professors, I believe that we’re the wrong people to use only our own experience and intuition when designing courses for non-CS majors, for a more diverse student population. Yes, we’re disciplinary experts, but that’s not enough. It is our responsibility to design the courses — on that, we’re agreed. It’s our responsibility to design for the students’ success.
One of my favorite quotes about computing education comes from Betsy DiSalvo and Amy Bruckman. “Computer science is not that difficult, but wanting to learn it is.” (See article here.) If we our goal is for students to learn computer science, we have to figure out will make them want to learn it.