Posts filed under ‘Uncategorized’

How to organize a state (summit): From ECEP and NCWIT

Soon after we started the Expanding Computing Education Pathways (ECEP) Alliance, we were asked: What should a state do first?  If they want to improve CS Education, what are the steps?

We developed a four step model — you can see a three minute video on ECEP that includes the four step model here. It was evidence-based in the sense that, yup, we really saw states doing this.  We had no causal evidence. I’m not sure that that’s possible in any kind of education public policy research.

One of those steps is “Organize.” Gather your allies. Have meetings where you CS Ed people rub elbows with the state public policymakers, like legislators and staffers in the Department of Education (or Department of Public Instruction, or whatever it’s called in your state).

A lot of states have had summits since then (see a list of some here).  Now, working with the fabulous NCWIT team of communicators, graphic designers, and social scientists, ECEP has released a state summit toolkit.  We can’t yet tell you how to organize a state. We can tell you how to organize a state summit.

From finding change agents to building a steering committee of diverse stakeholders, convenings play an important role in broadening participation in computing at the state level. ECEP and NCWIT have developed the State Summit Toolkit to assist leadership teams as they organize meetings, events, and summits focused on advancing K-16 computer science education.

From https://ecepalliance.org/summit-toolkit 

February 15, 2019 at 7:00 am Leave a comment

Need for Reviewers for US Department of Education CS Education Grants – Guest Post from Pat Yongpradit

Pat Yongpradit of Code.org asked me to share this with everyone.

The US Department of Education has announced the EIR grant competition for FY 2019. This year EIR incorporates an exclusive priority for computer science with a focus on increasing diversity and equity in access, as compared to last year where the highlight was that CS was merged with STEM as a combined priority. See more detail in our blog.

There are many moving parts to the federal grant review and award process, including a merit-based review process. In order to adequately score grants featuring computer science, the US Department of Education must have enough reviewers with K-12 computer science education experience. There is more information on the merit-review process and the Department’s mechanism for selecting reviewers in this blog.

Code.org has been asked to put interested folks in touch with leaders of the EIR grant program. If interested, please send your CV to EIRpeerreview@ed.gov.

Having CS knowledgeable reviewers participating in the federal grant review process is crucial to maximizing the opportunity these grants present the field and our collective goal of expanding access to K-12 computer science.

Best,

Pat

February 14, 2019 at 9:45 am Leave a comment

Hadi Partovi’s keynote at CrossRoads 2018: CS Ed Research needs to up its game

I was scheduled to be on a panel at last year’s InfoSys Crossroads 2018 conference, but my father passed the week before, so I couldn’t make it.  Several people told me that I had to see the video of Hadi Partovi’s talk, because “he talks about CS Education Research.”  The facial expression suggested I should feel warned.

I enjoyed the talk. Hadi made some critical and completely fair statements about CS Ed Research today. I recommend watching.

 

The really research-y stuff is around 30 minutes into the talk.  He talks about CS competing with other fields (a point that Joan Ferrini-Mundy also made to ECEP), and that CS has to make the argument for itself. I most appreciated the point (around 31:50) that no CS Ed research meets the “What Works Clearinghouse” standards for “works without reservations.” He’s right, and it’s a fair criticism.  Maybe it’s too early, but at some point, we have to be able to compete at the evaluation standards applied to all other subjects.  Code.org is stepping up their game, with the first evaluation demonstrating that their CSP curriculum significantly increases the rate at which students take and pass the AP CSP exam (see paper here).

I learned a lot from his talk, especially his points about how to scale. I love the advice to “Execute first, raise funding after.”  Since I’m trying to re-start my research program at Michigan, I am thinking about that advice a lot. I hear Hadi saying that I need to be executing on something interesting to fund first, before trying to sell the something interesting I want to do. Writing proposals about things I’m not executing on will probably not be convincing, and delays me making progress on the things I’m passionate about.

Of course, I vehemently agree with his argument that the future of CS Ed is to integrate CS into other subjects.

 

February 11, 2019 at 7:00 am 12 comments

Inverse Live Coding: A practice for learning web development

I finished my first semester teaching at the University of Michigan. I taught EECS 493 User Interface Development all on the WEb. It was a tough class for me since I had never before this class used JavaScript, jQuery, or CSS. I learned a lot, but I also had to teach it.

As readers of this blog now, I am a fan of live coding (see blog post here) where a teacher writes code live in front of the class. The positive aspects of live coding include that the teacher will likely make mistakes, so students see that (a) mistakes are common and expected, (b) mistakes can be corrected, and (c) there is a process to recover from mistakes.

I could not live code in this class. I didn’t know the material well enough. It took me too long to code, and I couldn’t recover from mistakes in front of the class.

It was also so hard in the context of a Web-based user interface course. I had the advantage that I could watch videos of Mark Ackerman and Walter Lasecki teach the course before me. Both of them know JavaScript and Web technologies well enough that they could live code in front of the class. I couldn’t understand what they were doing. Part of it was the low-resolution of the video — I couldn’t read the screens well. But a bigger part of it was the cognitive load of remembering the HTML and the CSS while writing the jQuery code. I couldn’t figure out the code while also remembering the names of the divs and how they were nested, and what CSS formats were being applied to which divs and classes. Maybe the younger kids fare better than me in my mid-50’s.

So, I tried a different practice. Maybe call it Inverse Live Coding.

  • I wrote programs (HTML, CSS, plus JavaScript with jQuery) before class.
  • I demoed and lectured on those programs (briefly — maybe 10-15 minutes).
  • Critical: I gave the students the code and all the associated files (HTML, CSS, and JavaScript).
  • Then, live in-class, I had students pair up to make small changes to the code.

This is like in-class coding or a lab session, but short — like 8-10 minutes of coding. We can do three of these in a lecture period. It’s more like a Peer Instruction (PI) session than a traditional laboratory coding activity.  I typically put 2-3 of these in a 90 minute class, as part of a lecture. I have students use iClickers to “click in” when they’re successfully done with the change, so we’re using PI practices to make clear what kind of activity this is. That ritual (clicking in then re-joining the class session) helps with bringing people back to the whole-class context after the pair-programming activity.

Here’s an example: I wrote a small JavaScript/HTML/CSS project that had a balloon slowly float upward, and could be steered left or right with arrow keys. (Why yes, that is a Smalltalk balloon in the example.)

I explained the code, introducing ideas like closures and the ready() method in jQuery.

Then I gave them a challenge. In this case, make the balloon also drift to the left, or drift in different directions based on the time or a random variable.

Different kinds of questions: I was pleased by how well this worked. First, it didn’t take much time. 80% of the teams solved at least one of the challenges in less than 8 minutes. Second, the teaching assistants and I got tons of questions. Many of the questions were fundamental ones — things I never would have even thought to talk about in class if I was live-coding. These are (paraphrased) actual questions that I got during the inverse live-coding sessions.

  • “Okay, I made the changes in the JavaScript. Now, how do I compile it?”
  • “I made the changes using the debugger in Chrome. How do I make this work in the CSS, HTML, or JavaScript files?”
  • “So, the jQuery is changing the HTML or the CSS, right? How come my file isn’t changing?”

These were pretty easy questions to handle in class, but one could imagine that those could stymie a student working alone. When I got one of these questions 1:1 or 2:1 during the pair-programming/live-coding, I made sure I answered the question for the whole class, too. These were questions about the fundamental nature of how Web technologies work (e.g., that the interpreter/compiler is the browser itself, and that jQuery says it’s changing CSS/HTML, but it’s really changing the DOM tree, etc.). It was much better to push the students to do the programming, and thus face these questions, than for the teacher to do the programming. The teacher would have an expert blind spot and may not even think to explain those parts that are invisible and confusing.

Miranda Parker suggested a variation of this practice. I could invite students to come up to the front of class to solve the problem, or to explain their solution after the session. That could be helpful in making sure that everyone sees something that works.

I would still use live coding in an intro course, when there aren’t invisible other files involved in the task and increasing cognitive load. In classes like Web Design, I will use inverse live coding more in the future.

February 4, 2019 at 7:00 am 9 comments

Come to my workshop on CS Education at ASEE June 16!

I am attending my first American Society for Engineering Education (ASEE) Conference this year — see the website here: https://www.asee.org/conferences-and-events/conferences/annual-conference/2019.

I’m still figuring out Engineering Education Research, so I’ll be offering a workshop based on our work at Georgia Tech: Techniques for Improved Engagement and Learning of Programming. The workshop is Sunday, June 16, 2019 from 9:00 am to noon. Please come, and please pass this on to others you know who are attending ASEE and might be interested.

Computing education research at Georgia Tech over the last 15 years has led to techniques for teaching programming which improve student learning. Learning is enhanced through greater engagement and reduced cognitive load.

These techniques are:

  • Media computation: Teaching programming through manipulation of digital media which improves students’ sense of utility and relevance leading to greater engagement;
  • Worked examples: Using worked examples in peer instruction and for prompting for predictions that improve learning;
  • Subgoal labeling: Structuring and labeling worked examples to improve immediate learning, retention over time, and transfer to new problems.

The learning objectives for this workshop are for participants to experience these techniques so that they might be able to judge which are most useful for their own practice. Participants will:

  • Manipulate digital media with programs that they write during the workshop (laptops required).
  • Participate in peer instruction questions using worked examples.
  • Compare worked examples with and without subgoal labeling.

 

February 1, 2019 at 7:00 am Leave a comment

The Ground Truth of Computing Education: What Do You Know?

Earlier this month, I was a speaker at a terrific event at Cornell Tech To Code & Beyond: Thinking & Doing organized by Diane Levitt (see Tweet here). I spoke, and then was on a panel with Kelly Powers, Thea Charles, Aman Yadav, and Diane to discuss what is Computational Thinking.

One of the highlights of the day for me was listening to Margaret Honey, a legendary educational technology designer and researcher (see bio here). She is President and CEO of the New York Hall of Science. One of my favorite parts of her talk was a description of the apps that they’re building to get kids to notice and measure things in their world. I even love the URL for their tools — https://noticing.nysci.org/

At the event, Diane mentioned that she was working on a blog post about her “ground truth” — what she most believed about CS education. She shared it as a tweet right after the event. It’s lovely and deep — find it here.

A couple of my favorite of her points:

Students thrive when we teach at the intersection of rigor and joy. In computer science, it’s fun to play with the real thing. But sometimes we water it down until it’s too easy—and kids know it. Struggle itself will not turn kids away from computer science. They want relevant learning experiences that lead to building things that matter to them. “I can do hard things!” is one of the most powerful thoughts a student can have.

The biggest lever we have is the one we aren’t using enough yet: preservice education for new teachers. The sooner we start teaching computer science education alongside the teaching of math and reading, during teachers’ professional preparation programs, the sooner we get to scale. It’s expensive and time-consuming to continually retool our workforce. Eventually, if every teacher enters the classroom prepared to include computer science, every student will be prepared for the digital world in which they live. This is what we mean by equity: equal access for every student, regardless of geography, gender, income, ability, or, frankly, interest.

Sara Judd answered Diane’s post with one of her own — find it here. I really enjoy it because she sees computer science like I do. It’s not just about problem-solving, but also about making things and connecting to the world.

Programming makes things.

While programming for it’s own sake can be fun for some people, (me, for instance) generally when people are programming it is because there is a thing that needs to be made. These things can be expressive pieces of visual art or music. These things can be silly fun for fun’s sake. These things can revolutionize the world, they can make our lives easier. The important thing is, they are “things.” CS doesn’t exist in a vacuum. Therefore, classroom CS should not exist in a vacuum.

I encourage more of us to do this — to write down what we believe about CS education, then share the essays. It’s great to hear goals and perspectives, both to learn new ones and also to recognize that others share how we think about it. I particularly enjoy reading these from people with different life experiences. I have a privileged life as a University CS professor. Teachers in K-12 struggle with very different things. I’m so pleased when I find that we still have similar goals for and perspectives about CS education.

January 28, 2019 at 7:00 am 1 comment

Older Posts


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

Join 6,143 other followers

Feeds

Recent Posts

Blog Stats

  • 1,607,264 hits
February 2019
M T W T F S S
« Jan    
 123
45678910
11121314151617
18192021222324
25262728  

CS Teaching Tips