My coauthor Wil Doane and I are open-sourcing our ICER 2016 submissions.

My coauthor Wil Doane and I are open-sourcing our ICER 2016 submissions. For each paper, you’ll find

  • A link to the Github repository, which contains not only the entire source code of each manuscript, but also the entire commit history. You can see how we went from initial commit to final product, browse our pull requests, and see blame views for the entire manuscript.
  • A PDF containing
    • The submitted paper itself
    • All reviewer reports (including a meta-review)
    • The ICER 2016 guidelines for reviewers
  • A link to a discussion issue, where I warmly invite you to leave feedback and start conversations
Title Download (PDF) Join the Conversation
Reconstructing design thinking and learning through code snapshots and clinical interviews (Source) Download It! Discuss It!
Expanding Models of Cognition within Computing Education Research (Source) Download It! Discuss It!

Why am I doing this?

I’m doing this for five reasons (at my current count):

  1. Teaching. In my entire graduate career, I never once saw the review history of a paper I didn’t write. And by and large, we don’t design our graduate courses around that. Sure, we pack our syllabi full of influential research and cornerstone pieces, but we don’t get to see how those pieces were made. We also don’t get to see how the community (in the form of reviewers) thought about and responded to those pieces, or what changed on their journey from initial submission to final acceptance. If that’s going to change—if we’re going to provide the community with worked examples of our own scholarship—it has to start somewhere. So I’m offering up my work.
  2. Exposing the Scholarly Writing Process. When I wrote my first first-author article, I filled a folder with more than 100 drafts of the manuscript. Each draft had entire conversations in the margin between me and my co-authors. The manuscript itself is now published, but what aren’t published are the dozens of conversations we had in those marginal comments, arguing (formally) with each other, persuading each other, convincing each other. The research was in the manuscript, but the dialectic was in the margins. We also had three separate rounds of review, and our second round included seven different reviewers. In each round we wrote the editor to respond to every single point the reviewers raised; in one of those rounds our letter to the editor was more than 10,000 words long. But none of that material—neither the marginal dialectics nor the carefully considered arguments we made to reviewers and editors—is available to current scholars. With this open-source project, you can start to see how Wil and I engaged in our authorial back-and-forth. It’s nowhere near a complete record of our conversations, but it’s a start.
  3. Continuing to Advance the Review System. Reviewing is hard, thankless work. And, odds are if you’ve submitted your work anywhere, you’ve experienced feeling like “the reviewers just don’t get it,” or “I addressed that on page 6!” or “Thanks, reviewer, for pointing out you’re dissatisfied while offering me no information on how to make you satisfied.” Our systems are imperfect, but we’re trying to make them better. And in that spirit, I’d like to point out a major disconnect between two different kinds of review I’ve been a part of. As an NSF review panelist, I’ve reviewed dozens of proposals where I had reservations or concerns. And every time I’ve raised a concern, the panel works to basically say “could the authors resolve your concern in a quick phone call/email, or is this the kind of concern that would require substantial revisions to the proposal?” The process of NSF reviewing allows for a certain limited back-and-forth with proposal authors, such that certain concerns can be triaged as not threatening the entire proposal. Our current ICER review process doesn’t work that way. We have no formal request-for-clarification/rebuttal mechanism. And, while I know about (and appreciate) the strides we’ve made with meta-reviews, I can easily identify comments in my reviews where having the chance to rewrite just one paragraph would have addressed reviewer concerns. If it’s happening to me, it might be happening to other people too.
  4. Keeping Knowledge Open. I think our scholarship should be as open as we can make it. If these papers had been among the 25% of papers accepted, they would—as far as I know—have been published behind the ACM digital library’s paywall. And while I know that not all CSEd research is publicly funded, this research was. The nation entrusted me and my colleagues with the means to investigate; I won’t betray that trust by making them pay again for my results.
  5. Fighting for the Legitimacy of Method. In their 2007 paper on acceptance and belonging in engineering education, Foor, Walden, and Tryttenden reflected on why they chose to conduct ethnographic research:
    Accepting qualitative research, especially ethnography of the particular, into the toolbox of engineering education research provides a microphone for the voices of the marginalized to be heard. Ethnography of the particular allows us to hear each and every voice that would otherwise be lost in aggregate ethnography or statistical analyses. (p. 113)

    I can’t claim that my ethnographic work is good enough to make it into ICER. The reviewers ultimately judged it wasn’t, and there’s no formal way for me to argue the case. What I can say with certainty is that those of us who conduct ethnographic work are still fighting for legitimacy in CSEd and engineering education. We still have to fight reviewers who have problems with ‘small-N’ studies, and the reviews you’ll see for my manuscripts prove it. And, to be clear, I’m not suggesting that, say, experimental design research doesn’t have to justify validity. It does. The difference is experimental designers have to defend their implementation of a research method; they don’t have to defend the epistemlogical legitimacy of that method. Put another way,—if research methods were objects—an experimental designer needs to defend their instance; ethnographers in CSEd have to defend the entire class itself. And ethnographers have to defend that class almost every time they want to publish in CSEd. Even though Erickson defended it in 1986. Even though Schoenfeld defended it again in 1994. And even though Andy Elby, Ayush Gupta, and I defended it again in 2014, with an entire section of our manuscript defending not just our instance of small-sample ethnography, but the rigor and value of the entire class of small-sample ethnography. If we have to justify our method’s legitimacy in every manuscript we write—even and especially when the venue is meant to represent the bleeding edge of CSEd research—it’s one more narrative burden, one more place reviewers can ding us, one more dimension that separates us from other kinds of research, and one more sign that while our community might say it embraces this method, we still have farther to go in making that true. And if you don’t believe that, reflect on the last time you got a reviewer comment that said “the problem with this study is that the N is just too large.”

References

Danielak, B. A., Gupta, A., & Elby, A. (2014). Marginalized identities of sense-makers: Reframing engineering student retention. Journal of Engineering Education, 103(1), 8–44. http://doi.org/10.1002/jee.20035
Erickson, F. (1986). Qualitative methods in research on teaching. In M. C. Wittrock (Ed.), Handbook of research on teaching (3rd ed, pp. 119–161). New York : London: Macmillan ; Collier Macmillan.
Foor, C. E., Walden, S. E., & Trytten, D. A. (2007). “I wish that I belonged more in this whole engineering group:” Achieving individual diversity. Journal of Engineering Education, 96(2), 103–115. http://dx.doi.org/10.1002/j.2168-9830.2007.tb00921.x
Schoenfeld, A. H. (1994). A Discourse on Methods. Journal for Research in Mathematics Education, 25(6), 697–710. http://doi.org/10.2307/749581

Window translucency behavior is weird in Yosemite screenshots

Apple’s translucent design in OS X 10.10 (Yosemite) has some weird consequences.

My friend Adam took a screenshot of Safari running on his Mac using Cmd+Shift+4. When he sent it to me, I used my iPhone to capture some odd behavior: when I tapped the image in our Messages thread, the appearance of the screenshot changed depending on whether the background I was viewing it under was black or white. When the background was black, the Safari window completely changed in appearance.

This color-changing behavior struck both of us as weird, because Adam sent me a static screenshot. The only explanation we could come up with was that in the screenshot Adam took, OS X included some alpha channel information for the safari window itself.

To test our guess, we both fired up Preview.app, opened the screenshot, and captured how it looked when we adjusted Preview’s “Window background” setting:

In Preferences you can change the default background color of Preview windows.

With a background set to white, the Safari window itself appears light, with well-defined delineations to visually separate tab titles. When we switched the background color to black, the Safari window darkened considerably, and tab delineations were much harder to spot. Curiously, changing the background color in Preview didn’t affect how the underlying wallpaper in the screenshot (in this case, flowers) looked at all. The background color change only affected the Safari window, which itself was in focus.

screenshot showing that in Preview.app with a black background color, the Safari window appears dark; in Preview.app with a white background, the Safari window appears light

This behavior isn’t necessarily “bizarre,” though it did for awhile have me convinced of some kind of hidden voodoo when I viewed the image on my iPad.

How I would improve my graduate program

At the end of the Ph.D. process, the department I graduated from sent me a survey about my experiences. I wanted to share the feedback I gave them on one specific question. Yes, it’s opinionated, and I welcome comments.

They asked:

How would you Improve your graduate program?

I answered:

The single biggest change I would suggest is a reform of the required two-course introductory statistics sequence for graduate students. (I took [multiple linear regression, the optional third course in the sequence] with [redcated] and I thought it was excellent and extraordinarily useful).

How would I change the course sequence? I’m not positive, but here are my suggestions:

  • The courses should focus on producing researchers who can be informed consumers and critics of quantitative work, even if (and especially if) the students in the course will not go on to be quantitative researchers
  • The courses need to be about thinking statistically, not following rote procedures for analysis in SPSS.
  • The courses should always use real datasets. Toy data sets are contrived, and they bypass so much of the work and thinking that goes into cleaning data. Worse, analyzing toy data produces toy results, which hardly help anyone.
  • Courses should focus on exploratory data analysis, including (and especially) visualizing data.
  • If the courses are going to incorporate doing statistical analysis, they should move away from SPSS. There’s no reason students should have to pay for statistics software when there are fantastic, FREE, industry-standard software toolkits to do statistics (including the R+Rstudio ecosystem and the iPython Notebook). Think about it: not only are we asking students to pay NOW when they take the courses, we’re also only teaching them that system, which means later in their careers they’ll have to spend more money to buy SPSS again, because it’s the only system they were trained on.
  • I really can’t emphasize that last point enough. With the graphical and statistical funcitonalities of R, Python, and other languages, I can’t think of a single reason this course should continue to be taught in SPSS, which costs money, graphically underperforms, and chains students to a for-pay software ecosystem.

Coverage of my Advanced Placement Exam data graphic

In a previous post I took a crack at re-visualizing data from high school Advanced Placement (AP) exams. I’m interested in the dataset because of what it shows about students’ participation in science, technology, mathematics, and engineering (STEM) subjects. But, I took a particular interest in how some outlets were representing the ratios of males to females who take the exam.1

My revised graphic of the AP exam data

I’m thrilled to find people are circulating my revised graphic. For example, Mark Guzdial used it in a post on his blog for the Communications of the ACM. There, he noted that not only does the graphic give a better sense of the gender ratios for all exams, it also reviews the overall low participation in AP Computer Science exams, shown by their small dot size.

I’m also excited to say that my graphic will be featured on the Visions of Science Vodcast. Visions of Science is a web video series focused on how scientific images convey meaning and aid understanding. The show is made possible through the generous support of The Association for the Cooperative Advancement of Science Education (ACASE), and I hope you’ll check it out once our episode goes live!

  • I’m trying to be careful here to use the terminology afforded by the data, in this case, “male” and “female.” For me, both personally and research-wise, biological sex and gender are substantially and consequentially different. I’ll leave my fuller views on gender out here, and suffice it to say that in general, I think gender is a text-field, not a binary radio button.  </fn></footnotes>
  • Creating a better data graphic for Advanced Placement exam data

    The background

    Danielle Kurtzleben at US News:

    During the past week, tech and education writers have been talking about data showing that the gender gap in the tech world is evident even in high school.

    They cite Barbara Ericson, director of computing outreach at Georgia Tech, who recently broke down the 2013 Advanced Placement exams and found that in three states (Mississippi, Montana, and Wyoming), zero girls took the AP computer science test. Even in the state where girls are best represented among computer science test-takers, Tennessee, girls only took 29 percent of the exams.

    US News then went ahead and made this graph, which Mark Guzdial linked to on his blog:

    graph of gender disparity in Advanced Placement courses

    From my best read, the graph is based off of the national numbers available directly from the college board.

    I think this graph has a number of great features:

    1. Since the TOTAL EXAMS bar at the top doesn’t break 1, we can see that there’s less than one female student taking an Advanced Placement (AP) exam for every one male student who takes one.
    2. The most egregious disparities where male test-takers outnumber females are in mathematics and science, because those bars are manifestly higher than the orange line which represents a 1:1 male:female ratio
    3. Of the math/science exams, computer science has the greatest gender disparity. More than four males took the test for every female who did.

    But, I think this graph isn’t as good as it could be, and here’s why:

    1. There’s no useful ordering the list of exams; they’re alphabetical. This lack of ordering is a classic case of what Howard Wainer (and subsequently Andrew Gelman) call the “Alabama First” error. When there’s a chance to order data in more meaningful ways, we should.
    2. This is a big one to me: a ratio cannot shrink below zero, but its growth is effectively unbounded. This graph has an x-axis which goes to zero. Empirically, it’s impossible for any test that a student actually took to have a zero ratio. But there’s an even bigger problem.
    3. The choice of a ratio scale means that there’s far less visual space to show classes where females vastly outnumber males. In French Language and Culture, for example, females outnumber males more than 2:1. That’s a greater disparity than the gender disparity in Calculus or Physics B. The gender disparity in Art History is also nearly 2:1, which makes it a far greater disparity than the 1.5:1 we see in Microeconomics. By setting a ratio scale that goes to zero, it’s much more difficult to spot the places where females may be greatly outnumbering males, which I would argue is also a gender problem.

    Making a better graph

    My mentor William E. J. Doane is fond of saying you shouldn’t criticize without offering a better solution. So, with my thanks to US News and Mark for getting me thinking about this, here’s my refined graph, made with help from Angela Zoss (click to embiggen)

    a reimagined plot of the ap exam data

    Why do I think this graph is more helpful?

    1. Instead of using a ratio scale, it uses a log-ratio scale. That means equal distances from the center line correspond to equal degrees of gender disparity. Computer Science A is still an extreme disparity (more than 4:1 females to males), but now we clearly see the cluster of studio art courses, all of which have a greater than 2:1 female/male ratio.
    2. It maps point size to total number of test takers. The disparity in computer science A is a problem, but one of the things that jumps out is that nearly three times as many students took English Language Composition, where the gender balance is decidedly skewed female rather than male. The same is true for English Literature Composition. And Psychology, which has roughly twice as many students taking it, also has more than 1.5 female test takers for every male test taker.
    3. Instead of alphabetical ordering, it orders by the degree of gender disparity. Computer Science and Studio Art are at the extremes. Science and math are toward the bottom. But what also stands out is the degree to which humanities-focused courses (art, romance languages) are imbalanced in favor of females, sometimes exceedingly so.

    Now it’s your turn

    I’ve open-sourced all of this work under an MIT license.

    Visions of Science

    We want you to help us with an experiment. My friends and I are starting up a video podcast on visualizations in science. We think of ourselves as Robert Krulwich‘s geeky, inquisitive extended family. But, we’re the weird branch that’s super-obsessed with visualizations. In each episode we’ll feature experts in science and representational domains having conversations with us.

    Our aims are to:

    • Disseminate powerful scientific visualizations to wider audiences
    • Promote the public’s understanding of scientific representations
    • Provide existing research projects a venue for engaging broadly with the public
    • Showcase positive, diverse role models for people considering careers in Science, Technology, Engineering, Arts, and Mathematics (STEAM) fields

    We made a (very rough) proof-of-concept episode that we want to share with you. And, with your support (see our survey we might be able to turn this into a professional reality).

    In this episode, we discuss:

    Things you should know before watching

    1. This was our first time. It’s a rough draft, it’s unedited, and there are ragged edges.
    2. We only had one hour to write, produce, record, and post this entire show. Imagine what we could do with more practice.
    3. Actual shows will never be this long (28 mins), but we wanted to illustrate different types of segments.
    4. With your help (by filling out the survey) we may be able to secure grant funding to get professional equipment and make high-quality future shows a reality.

    Please take our work in the spirit of a start, not a final product :-)

    Watch, and don’t forget the survey

    httpv://www.youtube.com/watch?v=lelKvmzGQ8M

    “They are free to use a construct that matches their intuition and meets their needs”

    For example, a well-known misconception among students learning about looping is the expectation that iteration can end in mid-loop, the instant a termination condition becomes true. And yet in this document I will present a language with looping constructs that work in just this way, are accepted as perfectly reasonable by inexperienced programmers, and are used by them to build effective robot behaviors. Does this mean that the old “misconception” can now be discarded as another artifact of the arbitrary requirements of an immature medium? Actually, in this case and many others, I think something much more interesting happens. What used to appear as a relatively isolated misconception is transformed into a part of a more general learning challenge with clearer connections to the rest of the world. In this case, for example, children still need (eventually) to master the differences between the two kinds of looping and the appropriate uses of each, along with parallel distionctions throughout the language. But in the meantime, they are free to use a construct that matches their intuitions and meets their needs.

    [Source][1]: (Hancock, Unpublished Doctoral Dissertation, p. 17)

    Using Calendar Programs to Think About Procedural Abstractions

    Abstract

    This post explores procedural abstraction, a fundamental concept of computer science and software design. First, I give a rough (and overly formal) definition of what I think procedural abstraction is. Then, I talk about a concrete issue from class: how can we think about procedural abstraction for a program that prints a 12-month calendar? I share my own representation for how I wrapped my head around what to abstract in a calendar program. Finally, I close with remarks about why procedural abstraction—both what it is and how it’s taught—might matter for my research.

    Intro

    Today’s class covered a whirlwind review of topics from Intermediate Programming. The early parts of class focused on some basics of the C language: input and output, primitive data types, procedural control (if/else, while, for loops), to name a few.

    But, when we got to talking about procedural abstraction. Procedural abstraction seems to be one of those things that everyone talks about but it’s hard to find a definition of. So, here’s mine:

    procedural abstraction: A name given to the process of observing, characterizing, unifying, and deploying an otherwise distributed (and re-used) set of instructions

    Pretty diffuse and hard to think-through, right?

    Below, I’ll go into great depth and describe how to think about procedural abstraction for the specific example of a program that prints 12-month calendars.

    Procedural Abstraction with calendar programs

    The instructor demonstrated a piece of C code ([year.c][1]) designed to print out a 12-month calendar. When you compile and run year.c, you get this:

    Enter a day of the week (0-6):
    

    You’re not told:

    1. That the input range 0-6 is supposed to be integers
    2. That each distinct integer represents a weekday
    3. That the weekdays are mapped consecutively to the integers, with Sunday being 0

    But, for this discussion those oversights aren’t important. What is important is that the program generates a 12-month calendar assuming that the first of the year falls on the day you specify as input.

    So, for example, the printed output of a single month (January) might look like this if you input 3:

    Su Mo Tu We Th Fr Sa
              1  2  3  4
     5  6  7  8  9 10 11
    12 13 14 15 16 17 18
    19 20 21 22 23 24 25
    26 27 28 29 30
    

    And multiple months would look like this:

    Su Mo Tu We Th Fr Sa
                     1  2
      3  4  5  6  7  8  9
     10 11 12 13 14 15 16
     17 18 19 20 21 22 23
     24 25 26 27 28 29 30
    
    
     Su Mo Tu We Th Fr Sa
      1  2  3  4  5  6  7
      8  9 10 11 12 13 14
     15 16 17 18 19 20 21
     22 23 24 25 26 27 28
     29 30 31
    
     Su Mo Tu We Th Fr Sa
               1  2  3  4
      5  6  7  8  9 10 11
     12 13 14 15 16 17 18
     19 20 21 22 23 24 25
     26 27 28 29 30
    

    Note that the months aren’t labeled (we’ll come back to that later).

    If you were a student being given that task for the first time, how might you decompose it? There are several sets of considerations that might occur to you:

    Visual Considerations

    1. How should the overall display be formatted?
    2. How can I wrap the days 1-31 around the calendar?
    3. Should the months appear side-by-side? In sequence?

    User Considerations

    1. Are we going to standardize on the Gregorian Calendar?
    2. Should the names of the weekdays be in English?
    3. What about leap years?

    But then there are the sets of concerns that are at the heart of the program’s logic. Beyond how it looks and what it affords, how should the thing work?

    The answer to how it should work depends on how you see the problem. It also depends on whether you see certain aspects of the problem space you can exploit. Since different months have different numbers of days (30 vs. 31), you might decide to write a code section for each month.

    Below is the code section for January. It assumes weekDay is the number of which day of the week (0-6) starts the month of January. Also, the percent sign (%) indicates modulo division; that’s actually a pretty clever way of solving the display problem “how do we wrap dates around when the week ends?”

    /* Print January */
    printf(" Su Mo Tu We Th Fr San")
    
    /* prints spaces before the first date is printed */
    for (i = 0; i < weekDay; i++) {
      printf("   ");
    }
    
    /* prints the dates */
    for (i = 1; i <= 31; i++) {
      printf("%3d", i);
      if (!((i+weekDay) % DAYS_IN_WEEK))
        printf("n");
    }
    printf("n");
    

    If you write one section for each month—and you do it by hand—then the section for February would look similar. Except the tough part is, February starts the day after January ends. So, how do you handle which day to print first in February?

    The answer isn’t necessarily obvious, though here’s one way to think about it. January starts on whatever day the user passes in (0-6). February starts 31 days after that. So, the weekday February starts on is whatever day of the week is [user input] + 31.

    So, one way to figure out February’s starting day is to add 31 days to January’s starting day, then wind those days into 7 day week-segments and see what’s left over. Sounds like a job for modulo arithmetic (% in C).

    /* Print February */
    int februaryStart = (weekDay + 31) % 7;
    
    printf("n"); // To make space for the next month
    printf(" Su Mo Tu We Th Fr San");
    
    /* prints spaces before the first date is printed */
    for (i = 0; i < februaryStart; i++) {
      printf("   ");
    }
    
    
    /* prints the dates */
    for (i = 1; i <= 28; i++) {
      printf("%3d", i);
      if (!((i + februaryStart) % DAYS_IN_WEEK))
        printf("n");
    }
    printf("n");
    

    This code works. It prints each month and it adjusts the number of days it prints depending on the month. Mission accomplished, right?

    Here’s the part where we presume students see the computational and design inefficiencies that experts would see in this code

    This code is wasteful. Can you see why?

    Actually, if I hadn’t said it was wasteful would you have even thought it was? Do you think students would have thought it was?


    Here’s where it’s wasteful:

    1. This line will end up being repeated exactly as it’s written 12 times, one for each month: printf(“ Su Mo Tu We Th Fr Sa\n”)
    Take a second. Remember what the output months look like
      
    when they&#8217;re printed, given the pattern, and convince
      
    yourself that every month has the same seven weekdays in it:
    
         /* Print January */ 
         printf(" Su Mo Tu We Th Fr Sa\n")
        
         ...
        
         /* Print February */ 
         printf(" Su Mo Tu We Th Fr Sa\n")
        
         ...
        
         /* Print March */ 
         printf(" Su Mo Tu We Th Fr Sa\n")
    
    1. For every month, we’re going to want to print each day in the month. But that means we’re essentially repeating this statement: c for (i = 0; i <= 28; i++)
    and only fiddling with the upper limit of `i` (since all months start at 1, but some end at 28, 29, 30, or 31) . So, the pattern means a top-level view of repetition in our code looks like this:
    
        for (i = 0; i <= 31; i++) // January
        for (i = 0; i <= 28; i++) // February
        for (i = 0; i <= 31; i++) // March
        for (i = 0; i <= 30; i++) // April
    
    1. For every month, we’re going to want to wrap weeks around the display, so that each 7-day-week of the month is on a new line of the output. Notice how similar the wrapping code for January looks to the wrapping code for February //January printf(“%3d”, i); if (!((i+weekDay) % DAYS_IN_WEEK)) printf(“\n”);

      //February printf(“%3d”, i); if (!((i + februaryStart) % DAYS_IN_WEEK)) printf(“\n”);

    How can we really start to appreciate the wastefulness?

    I created the slideshow below to offer a fuller sense of where and why this code is wasteful.

    ProceduarlAbstraction

    Seeing wastefulness as a way in to procedural abstraction

    If you look at how the code is wasteful, what you see is

    1. Identical procedures get repeated
    2. The procedures are repeated on very similar objects (months) for very similar reasons (we need to print each month)
    3. There are elements of commonality in how the procedures differ

    In fact, if you look at slide 5 above, the only bits of unique code1 that matter are weekDay and februaryStart. When you look at it that way, it might become obvious that all months of a calendar have 7-day-weeks, and they only really differ in

    1. How many days are in the month
    2. What day of the week starts the month (weekDay and februaryStart are both different names for this same general idea)

    To a sharp programmer, then, all the groundwork is there for a procedural abstraction. But now, ask yourself: is it obvious what the abstraction should look like? How do we begin to understand wastefulness? And, how does noticing a pattern of waste in code bring us to a point where the form of a new abstraction is clear?

        // Determine the day offset that starts the month
        // Print enough blank spaces to offset the start 
        //     of the month from Sunday
        // Print a number for each day of the month
        // Wrap a display line when you finish a week
    

    From wastefulness to abstraction

    Hopefully, I’ve convinced you by now that—in the case of the calendar—seeing the wastefulness can be tightly coupled to developing a procedural abstraction. For myself, I needed to generate my own kind of representation (seen in the slideshow above) to explore common patterns in wastefulness.

    I don’t know how other programmers operate, but I find that I can’t move to a level of procedural abstraction without first crafting a clear connection between repetition of code and patterns in procedure. In my slideshow I did that visually—lots of other people might have other ways.

    Why this matters for my study

    The (at times) extremely fast pace of Intermediate Programming can mean the instructor doesn’t have time to explore the subtleties of sample code. My field notes indicate the instructor discussed the abstraction mechanism in year.c for about 10 minutes. In his full defense, 10 minutes can be an extensive and thorough use of lecture time. Furthermore, I imagine the topic will come up many times throughout the semester. So, I’m not just noticing the amount of time given the topic; I’m also noticing the tone and structure of the discussion in that time.

    The instructor started the procedural abstraction discussion by opening year.c and showing students the already-abstracted print_month() procedure:

    void print_month(int weekDay, int monthDay)
    {
      int i;
    
      /* print header line */
      printf(" Su Mo Tu We Th Fr San");
    
      /* prints spaces before the first date is printed */
      for (i = 0; i < weekDay; i++) {
        printf("   ");
      }
    
      /* prints the dates */
      for (i = 1; i <= monthDay; i++) {
        printf("%3d", i);
        if (!((i+weekDay) % DAYS_IN_WEEK))
          printf("n");
      }
      printf("n");
    }
    

    The rest of the discussion was about why this was an obviously better alternative to writing separate procedures for each month. So, the concern here is something Wil would call “giving students solutions to problems they don’t have yet,” or, “handing solutions to students who may not yet realize why the problem even matters.”

    If I were a cognitive-constructivist, I’m not quite sure I’d know what to make of the instructor’s approach. Part of me believes that helping students construct knowledge of procedural abstraction should entail an authentic appreciation of what problems might call for it. But, it seemed to me that my creation of the slideshow graphics above was my way of constructing a sense of procedural abstraction for this problem. Furthermore, it gave me a visual metaphor to think with—a pathway to move from an observing wasteful code to identifying common elements, and ultimately wrapping my mind around what pattern was getting repeated.

    I think then, that one open question for me is: how do students think about and see procedural abstractions in their own work of trying to solve problems.

  • excluding comments, which look //like this or /* like this */  </fn></footnotes>
  • “A ‘pre- and post- test’ at age two would have missed them”

    This book is an exercise in an applied genetic epistemology expanded beyond Piaget’s cognitive emphasis to include a concern with the affective. It develops a new perspective for education research focused on creating the conditions under which intellectual models will take root. For the last two decades this is what I have been trying to do. And in doing so I find myself frequently reminded of several aspects of my encounter with the differential gears. First, I remember that no one told me to learn about differential gears. Second, I remember that there was a feeling, love, as well as understanding in my relationship with gears. Third, I remember that my first encounter with them was in my second year. If any “scientific” educational psychologist had tried to “measure” the effects of this encounter, he would probably have failed. It had profound consequences but, I conjecture, only very many years later. A “pre- and post-” test at age two would have missed them. (Papert, 1980, pp. vii-viii); emphasis in original

    As I begin my odyssey into the comps process, I’ve tried to start at a useful beginning: the writings of Seymour Papert. Papert’s 1980 book Mindstorms is regarded by many—at least in the fields of education and learning sciences—as a classic on how children learn with computers. In the beginning of the book he describes being curious about gears as a child and how that curiosity helped him build his own personal ways of knowing about mathematics. What I’d like to do in this post is take apart some of the assertions Papert makes in the above-quoted passage, which is excerpted from the book’s foreword: “The Gears of My Childhood.”

    First, Papert calls his book an “exercise in an applied genetic epistemology.” But, what does he mean by genetic epistemology? For that matter, if there is an “applied” kind of genetic epistemology, could there be another kind? Let’s step back for just a moment. The phrase “genetic epistemology” itself traces as far back at least as Jean Piaget, with whom Papert worked for several years. In a previous paragraph, Papert writes:

    I was developing a way of thinking that would be resonant with Piaget’s. The understanding of learning must be genetic. It must refer to the genesis of knowledge. What an individual can learn, and how he learns it, depends on what models he has available. This raises, recursively, the question of how he learned those models. Thus, the “laws of learning” must be about how intellectual structures grow out of one another and about how, in the process, they acquire both logical and emotional form. (Papert, 1980, p. vii; emphasis in original)

    I think Papert’s summary of genetic epistemology is clear enough for now, though I’ll add one historical and interpretive note. In my understanding of Piaget—an understanding based on admittedly brief slice of the man’s work: his 1970 article on his own theory—what Piaget sought was an explanation for where knowledge comes from. Specifically, he wanted to know where structures of knowledge come from. Most scholars I’ve talked to who study Piaget argue that his training in both biology and philosophy deeply influenced his search for how structures of knowledge come to be. In short, if there is some base structure (viz. DNA) that co-directs how physical biological structures (arms, eyes, hurty parts on insects) emerge and develop, might one not also search for the epistemological developmental structures that co-direct how knowledge (and its forms) develop. That, in one wordy sentence, is my nutshell read of the relevant Piaget bits for this discussion. Back to Papert.

    “both logical and emotional form”

    Piaget’s original work—summarized in his 1970 article—sketches a possibility for the genesis of the logical forms of knowledge humans develop. It is, rather chiefly, concerned with structures responsible for our abilities to reason about quantities, forms, and conservation. But it’s not about emotion. Piaget didn’t attempt to explain how it feels to reason about coins and fluids. Piaget also doesn’t address the role of emotion in the building of cognitive structures.

    Papert, in defense of Piaget, suggests Piaget was far from ignorant about the whole thing. Below, he argues that Piaget wasn’t blind to the role of emotion in assimilation—assimilation being Piaget’s word for how we graft new knowledge, in light of experience, to our current cognitive structures. Below, Papert explains:

    [Piaget] talks almost entirely about cognitive aspects of assimilation. But there is also an affective component. Assimilating equations to gears certainly is a powerful way to bring old knowledge to bear on a new object. But it does more as well. I am sure that such assimilations helped to endow mathematics, for me, with a positive affective tone that can be traced back to my infantile experiences with cars. I believe Piaget really agrees. As I came to know him personally I understood that his neglect of the affective comes from a modest sense that little is known about it than from an arrogant sense of its irrelevance.

    Throughout the foreword, Papert argues that his own experience with gears wasn’t just knowledge-building. Rather, his interaction with gears became a form of emotional knowledge building. For me, it’s difficult to disagree with Papert. Affect, knowledge-building, and knowledge-use are interconnected to far too high a degree. If, for example, I think about a poem excerpt, I think both of how I felt when I read it, how reading it changed the way I read poetry, and how that resultant change gave me the confidence to keep reading poetry. At the Honors Convocation ceremony of my college graduation, my mentor read to us a poem called “At The Border” by Carl Dennis. The poem begins:

    At the border between the past and the future

    No sign on a post warns that your passport

    Won’t let you return to your native land

    As a citizen, just as a tourist

    I was astounded. I was moved. I had never before thought of my graduation experience—or of any part of moving on in life—in the plainspoken yet profound way the poem suggested. But there I was, ironically, at the border, and being paradoxically warned for that brief moment in time that no sign would let me know I couldn’t come back.

    The experience stuck with me. I’ve remembered the poem, but also the experience of trying to make sense of it. I’ve also remembered to keep trying; to look for new poetic experiences. I think that’s what Papert’s after when he talks about the importance of the emotional in building knowledge forms. It’s about much more than being happy when one learns; it’s about recognized that the feelings we have as we learn become part of the matrix of what we learn, and how that knowledge continues to integrate as we move forward with new experiences.

    “creating the conditions under which intellectual models will take root”

    This is what we’re all about. If learning derives from models, and we build models in part with and around emotional experiences, then understanding “the conditions under which intellectual models will take root” might well be the most important question we strive to answer with research on learning.

    Except I think it’s easy to get distracted. It’s easy to think that what Papert means as “conditions” are things like how we build our schools, how we design our lessons, and what technology is (or isn’t) available. But those are material conditions. To me, they’re a subset of all the things we could think about when we mean conditions.

    Again, let’s revisit Papert’s (1980, pp. vii-viii) three assertions in the original quote, paraphrasing where needed to make the point:

    1. No one told me to learn about differential gears
    2. I felt a feeling, love, as well as an understanding in my relationship with gears
    3. I was two; a pre- post- test at the time was hardly an option to measure my learning

    Point 1 isn’t about material conditions at all, really. If anything, it’s about the lack of externally-imposed constraints. Point 2, on which I elaborated quite a bit, seems to say that emotion is as much a building material in constructivism/constructionism as is any knowledge or sensory element. Point 3? We can have meaningful experiences with the world that many of the research methods we deploy in education would fail to capture.

    References

    Dennis, C. (2007). Unknown Friends. New York: Penguin Books. Retrieved from http://lccn.loc.gov/2006050716

    Papert, S. (1980). Mindstorms: Children, Computers, and Powerful Ideas. New York: Basic Books. Retrieved from http://lccn.loc.gov/79005200

    Piaget, J. (1970). Piaget’s Theory. In P. H. Mussen (Ed.), Carmichael’s Manual of Child Psychology (3rd ed., Vol. 1, pp. 703-732). New York: Wiley. Retrieved from http://lccn.loc.gov/69016127

    ICER 2011 Core Dump

    I heard so many interesting talks, met so many provocative people, and thought so hard about computation that I’ll never hear the words “this is a test” the same way again.

    One highlight for me was talking with Mark Guzdial about pictures and sounds as transformations of binary information. As I continue to think about intersecting possibilities for our brand of scientific inquiry and what promise it might hold in CS, I’m definitely going to turn my attention toward core concepts in how we represent information. More importantly, perhaps, are issues of how we generate, modify, and understand information.

    Another was raising issues of what counts as evidence, and how we define learning. I really look forward to having more interesting conversations about what we think we’re studying when we try to study student learning.

    A third was getting to continue ongoing conversations about education with friends, both old and new. To me, the heart of a good conference is the way our interests and ideas about central problems in the field spill outside the bounds of sessions and talks. These conversations are what excite and energize me.

    Finally, I had an amazing time at the pre-conference Doctoral Consortium (DC). I was able to meet colleagues from across the world who are starting (or, in some cases wrapping up) their dissertations. It was a thrill to see the variety of problems people are taking on and an amazing opportunity to both get and give detailed feedback on our work.

    Beginning work on epistemological dynamics in programming

    I’m preparing for my comprehensive examinations (comps), which are essentially three in-depth essays written and revised under the direction of a faculty member. My second comp is actually my work on a statistical graphics package called granova, but I’ll be discussing that subject in another post. Here, I want to talk about my third comp, which will hopefully become the springboard to a dissertation proposal.

    If I’m doing my job right, this post will grow into a much larger series of posts, and hopefully (when well-watered, cared for, and nourished) a dissertation. To get there, here are some of the core questions I think I’ll need to address.

    1. What are epistemological dynamics? What do I mean when I’m talking about epistemologies and epistemological dynamics? What does that idea do as a technical construct?
    2. Where do epistemological dynamics come from? What’s their genesis as a research construct? More to the point, what do they allow us to explain and predict?
    3. Why do epistemological dynamics matter for learning to program? This has to go beyond simply arguing that “they matter.” Many, many things affect the ways individuals learn to program. The subquestions here surround how we can use the study of epistemological dynamics in programming?
      1. Can they push research efforts forward, illuminating erstwhile unseen problems?
      2. Can they push the theoretical discussion forward, explaining the otherwise un- or underexplained?
      3. Finally, can they inform pedagogy? Can epistemological dynamics help us craft educational experiences around programming that attract, retain, and empower students?

    As part of my work preparing for the 2011 International Computing Education Research Conference (ICER), I’ll be working through a presentation that tries to flesh out these issues. The goal there is to craft a form of these dissertation ideas that conference attendees can critique. Keep your eyes on the blog as I continue to expand my ideas and hopefully tackle—or refine—the above roadmap of questions.