Posts tagged ‘end-user programmers’

What do I mean by Computing Education Research? The Social Science Perspective

As a new guy at the University of Michigan, I spend a lot of my time explaining who I am and what I mean by computing education research. In this and the next blog posts, I am sharing two of those explanations.

The first one was a six minute lightning talk to the University of Michigan School of Information. My audience was well-versed in social sciences, so I explained who I was in those terms.

I ground a lot of my work in Lave and Wenger’s (1991) theory about Communities of Practice. Let me create a symbol here to represent a community of practice. My symbol has a light boundary where novices engage in legitimate peripheral participation, there is a darker area where full-fledged members of the community work, and the core where the experts live who represent the values and practices of the community.

When people think about computing education research, they mostly think about this community of practice: software development. How do we help students join the community of practice of software developers? That’s an interesting question, and I have done some work there (e.g., on how students come to understand multiple class object-oriented systems, like Model-View-Controller), but that’s not my focus.

Let’s set that community of practice aside (lower left), and consider another that I’m much more interested in: end-users who program. I’ve taught thousands of liberal arts, architecture/design, and business/management majors to program using Media Computation, a contextualized approach to computing that focuses on their interests and needs. I worked with Brian Dorn as he studied graphics designers who learn to program. End-user programmers are far more numerous than professional software developers. They use programming for different purposes, so we would expect them to use different practices, languages, libraries, and tools. That’s why we developed JES, a Python programming environment for our future end-users who are programming with media. I’m very interested in understanding and supporting the practices of end-user programmers.

Let’s keep that community of practice in consideration, and next consider a different one: High school teachers who teach computer science. They’re not about software development, either. They’re going to do something different (different practices) and have different values. High school teachers need to learn efficiently because they don’t have a lot of time to learn, and they want to learn effective methods for their students. Here’s where we work on ebooks, and subgoal labeling, and Barb’s Parsons problems. I’m interested in how we make computing education efficient and effective, and in understanding the underlying cognitive mechanisms at work. Why do some things work better for learning programming than others?

Here’s another community of practice I care about: scientists and engineers who use programming as a new way to do science. Again, different practices and values than software developers. How do we best support them?  What tools do they need for their practices?

I would like students to have the same advantages as scientists and engineers, to be able to use code as a powerful and executable notation. Lately, I’ve been particularly focused on pre-calculus and economics. I know it’s stretching Lave and Wenger’s notion to think about classrooms as kinds of community of practice, so maybe the real community of practice is economists and professionals who use Computing. My specific interest is the edge of the community of practice, constructing legitimate peripheral participation for students who might use computing to aid in their entrance into the field. When does programming help with learning something else, and why does it help, and how can we make it more effective (e.g., use the best parts of programming that have the greatest leverage on supporting learning)?

So let’s consider these communities of practice.

This is a really weird picture, from Lave and Wenger’s perspective. I’m saying that programming is a practice in all of these communities, but it’s different in each one. We actually do know practices like this: Reading and writing, and the use of mathematics.

I suggest that programming is a literacy. (I’m not the first, of course, and I don’t make the argument nearly as well as my colleague, Yasmin Kafai.) It’s a way of expressing thought, communicating with others, and testing and exploring new ideas.

And that’s what makes computing education a social justice issue. If we have really invented a new literacy, we need to make it available to everyone.

November 5, 2018 at 9:00 am 11 comments

Reflections of a CS Professor and an End-User Programmer

In my last blog post, I talked about the Parsons problems generator that I used to put scrambled code problems on my quiz, study guide, and final exam. I’ve been reflecting on the experience and what it suggests to me about end-user programming.

I’m a computing professor, and while I enjoy programming, I mostly code to build exercises and examples for my students. I almost never code research prototypes anymore. I only occasionally code scripts that help me with something, like cleaning data, analyzing data, or in this case, generating problems for my students. In this case, I’m a casual end-user programmer — I’m a non-professional programmer who is making code to help him with some aspect of his job. This is in contrast:

  • To Philip Guo’s work on conversational programmers, who are people who learn programming in order to talk to programmers (see his post describing his papers on conversational programmers). I know how to talk to programmers, and I have been a professional programmer. Now, I have a different job, and sometimes programming is worthwhile in that job.
  • To computational scientists and engineers, which is the audience for Software Carpentry. Computational scientists and engineers might write code occasionally to solve a problem, but more importantly, they write code as part of their research.  I might write a script to handle an odd-job, but most of my research is not conducted with code.

Why did I spend the time writing a script to generate the problems in LaTeX? I was teaching a large class, over 200 students. Mistakes on quizzes and exams at that scale are expensive in terms of emails, complaints, and regrading. Scrambled code problems are tricky. It’s easy to randomly scramble code. It’s harder to keep track of the right ordering. I needed to be able to do this many times.

Was it worthwhile? I think it was. I had a couple Parsons problems on the quiz, maybe five on the study guide, and maybe three on the final exam. (Different numbers at different stages of development.) Each one got generated at least twice as I refined, improved, or fixed the problem. (One discovery: Don’t include comments. They can legally go anywhere, so it only makes grading harder.) The original code only took me about an hour to get working. The script got refined many times as I used it, but the initial investment was well worth it for making sure that the problem was right (e.g., I didn’t miss any lines, and indentation was preserved for Python code) and the solution was correct.

Would it be worthwhile for anyone else to write this script facing the same problems? That’s a lot harder question.

I realized that I brought a lot of knowledge to bear on this problem.

  • I have been a professional programmer.
  • I do not use LiveCode often, but I have used HyperTalk a lot, and the environment is forgiving with lots of help for casual programmers like me. LiveCode doesn’t offer much for data abstraction — basically, everything is a string.  I have experience using the tool’s facility with items, words, lines, and fields to structure data.
  • I know LaTeX and have used the exam class before. I know Python and the fact that I needed to preserve indentation.

Then I realized that it takes almost as much knowledge to use this generator. The few people who might want to use the Parsons problem generator that I posted would have to know about Parsons problems, want to use them, be using LaTeX for exams, and know how to use the output of the generator.

But I bet that all (or the majority?) of end-user programming experiences are like this. End-users are professionals in some domain. They know a lot of stuff. They’ll bring a lot of knowledge to their programming activity. The programs will require a lot of knowledge to write, to understand, and to use.

One of the potential implications is that this program (and maybe most end-user programs?) are probably not useful to many others.  Much of what we teach in CS1 for CS majors, or maybe even in Software Carpentry, is not useful to the occasional, casual end-user programmer.  Most of what we teach is for larger-scale programming.  Do we need to teach end-user programmers about software engineering practices that make code more readable by others?  Do we need to teach end-user programmers about tools for working in teams on software if they are not going to be working in teams to develop their small bits of code? Those are honest questions.  Shriram Krishnamurthi would remind me that end-user programmers, even more than any other class of programmers, are more likely to make errors and less likely to be able to debug them, so teaching end-user programmers practices and tools to catch and fix errors is particularly important for them.  That’s a strong argument. But I also know that, as an end-user programmer myself, I’m not willing to spend a lot of time that doesn’t directly contribute towards my end goal.  Balancing the real needs of end-user programmers with their occasional, casual use of programming is an interesting challenge.

The bigger question that I’m wondering about is whether someone else, facing a similar problem, could learn to code with a small enough time investment to make it worthwhile. I did a lot of programming in HyperTalk when I was a graduate student. I have that investment to build on. How much of an investment would someone else have to make to be able to write this kind of script as easily?

Why LiveCode? Why not Python? Or Smalltalk? I was originally going to write this in Python. Why not? I was teaching Python, and the problems would all be in Python. It’d good exercise for me.

I realized that I didn’t want to deal with files or a command line. I wanted a graphical user interface. I wanted to paste some code in (not put it in a file), and get some text that I could copy (not find it in one or more files). I didn’t want to have to remember what function(s) to call. I wanted a big button. I simply don’t have the time to deal with the cognitive load of file names and function names. Copy-paste the sorted code, press the button, then copy-paste the scrambled code and copy-paste the solution. I could do that. Maybe I could build a GUI in Python, but every time I have used a GUI tool in Python, it was way more work than LiveCode.

I also know Smalltalk better than most. Here’s a bit of an embarrassing confession: I’ve never really learned to build GUIs in Smalltalk. I’ve built a couple of toy examples in Morphic for class. But a real user interface with text areas that really work? That’s still hard for me. I didn’t want to deal with learning something new. LiveCode is just so easy — select the tool, drag the UI object into place.

LiveCode was the obvious answer for me, but that’s because of who I am and the background that I already have. What could we teach future professionals/end-user programmers that (a) they would find worthwhile learning (not too hard, not too time-consuming) and (b) they could use casually when they needed it, like my Parsons problem generator? That is an interesting computing education research question.

How does a student determine “worthwhile” when deciding what programming to learn for future end-user programming?  Let’s say that we decided to teach all STEM graduate students some programming so that they could use it in their future professional practice as end-user programmers.  What would you teach them?  How would they judge something “worthwhile” to learn for later?

We know some answers to this question.  We know that students judge the authenticity of the language based on what they see themselves doing in the future and what the current practice is in that field (see Betsy DiSalvo’s findings on Glitch and our results on Media Computation).

But what if that’s not a good programming language? What if there’s a better one?  What if the common practice in a field is ill-informed? I’m going to be that most people, faced with the general problem I was facing (wanting a GUI to do a text-processing task) would use JavaScript.  LiveCode is way better than JavaScript for an occasional, casual GUI task — easier to learn, more stable, more coherent implementation, and better programming support for casual users.  Yet, I predict most people would choose JavaScript because of the Principle of Social Proof.

I’ve been reading Robert Cialdini’s books on social psychology and influence, and he explains that social proof is how people make decisions when they’re uncertain (like how to choose a programming language when they don’t know much about programming) and there are others to copy.

First, we seem to assume that if a lot of people are doing the same thing, they must know something we don’t. Especially when we are uncertain, we are willing to place an enormous amount of trust in the collective knowledge of the crowd. Second, quite frequently the crowd is mistaken because they are not acting on the basis of any superior information but are reacting, themselves, to the principle of social proof.

Cialdini PhD, Robert B.. Influence (Collins Business Essentials) (Kindle Locations 2570-2573). HarperCollins. Kindle Edition.

How many people know both JavaScript and LiveCode well?  And don’t consider computer scientists. You can’t convince someone by telling them that computer scientists say “X is better than Y.”  People follow social proof from people whom they judge to be similar to them. It’s got to be someone in their field, someone who works like them.

It would be hard to teach the graduate students something other than what’s in common practice in their fields, even if it’s more inefficient to learn and harder to use than another choice.

June 11, 2018 at 2:00 am 2 comments

Most jobs requiring CS skills do not require a CS degree #CSEdWeek

I am excited about this new report from Burning Glass and Oracle because it provides evidence for the claim that the vast majority of people who need CS skills will not be CS majors.  I will be joining folks from Burning Glass and Alison Derbenwick Miller and others from Oracle Academy in a Twitter chat about the report Wednesday, December 6 at 4 pm PT/7 pm ET.  Hope you can join us.

Only 18% of these jobs specifically request a computer science degree

While many employers are looking for workers with strong computer science skills, they are not necessarily looking only at job seekers with computer science degrees. Only 18% of jobs in the categories listed above specifically request a computer science degree. (Most postings do request a bachelor’s degree generally or a degree in another major.) Programming and data analysis jobs are the only categories that have significant demand for computer science degrees. For all other categories, fewer than 5% of postings request a computer science degree.[1] This means that students in a broad range of education programs can enhance their job market value by including computer science in their education pathways.

Source: Rebooting Jobs | Computer Science Skills | Burning Glass Technologies

twitter-chat

December 5, 2017 at 7:00 am 2 comments


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

Join 4,354 other followers

Feeds

Recent Posts

Blog Stats

  • 1,587,380 hits
December 2018
M T W T F S S
« Nov    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

CS Teaching Tips