October 23, 2014 4:21 PM
A Quick Word on the Yik Yak Controversy
There has been some controversy on my campus recently about a slew of hurtful posts made on the social media application Yik Yak. The following is something I wrote for my intro CS students, with minor changes.
Computing is often in the news, but we don't talk much about current events in class. That's not the focus of this course, and we have plenty to do...
But the recent news story in the Northern Iowan about Yik Yak has been on my mind. Yik Yak is a social media app that lets people make comments anonymously and vote on other people's comments. This kind of app has many possible uses, some of which are positive. Many people live under conditions where they need to be able to communicate anonymously.
Unfortunately, some people in the UNI area have been using it to post hurtful comments about various groups. This behavior is simply mean.
Yik Yak is a social app, so the controversy is about people and how they behave. In this regard, my reaction has been similar to so many others' reactions. I am always sad to be reminded that people actually think such things, and sadder to know that they feel compelled to say them out loud. To do so anonymously is an act of cowardice.
But this controversy is also about what we do, because Yik Yak is a program. We call it an "app", but that's just the term du jour. It is a computer program. Programmers wrote it.
We could have an interesting discussion about apps like this: their uses, the good and bad they enable, how to grow and guide communities of users, and so on. I do not use Yik Yak and am not a member of its community. I don't know much beyond what has been reported about it in the media. However, I have been part of Internet-based communities since I was in college, and they all seem to have a lot in common with one another. So this situation feels quite familiar to me.
I am not going to lecture a group of young people about the ways they communicate and congregate on-line. Let me just say this.
When you learn to program, you inherit power to affect the world. You can make things, programs and apps and services that real people use. You can choose to use your power to do good things, to make the world better. Or you can not choose to. Not choosing may mean creating something whose effects you did not consider, or whose community behaves in ways you did not intend.
Please take your power seriously. Think about the effects of what you do when you write a program. Choose wisely.
October 22, 2014 4:32 PM
The Meaning of Life
... is determined by the moments when something happens.
In the end, a person doesn't view his [or her] life as merely the average of its moments -- which, after all, is mostly nothing much, plus some sleep. Life is meaningful because it is a story, and a story's arc is determined by the moments when something happens.
So writes Atul Gawande in Being Mortal: Medicine and What Matters in the End. When I am deep in a semester, preparing a course and doing all the things that a department head must do, both big small, the pace of life reaches a point where my mind is prone to go into cruise control. That's when I need to remind myself not to let my story become a stretch of uninterrupted white noise. I have to consciously step out of the blur and make something worthwhile -- and memorable -- happen.
October 21, 2014 3:13 PM
Ernest Hemingway, Programmer
In The Wave in the Mind, a collection of talks and essays, Ursula Le Guin describes Ernest Hemingway as "someone who did Man right". She also gives us insight to Hemingway's preferences in programming languages. Anyone who has read Hemingway knows that he loved short sentences. Le Guin tells us more:
Ernest Hemingway would have died rather than have syntax. Or semicolons.
So, Java and C are out. Python would fit. Or maybe Lisp. All the greats know Lisp.
October 17, 2014 3:05 PM
... on how the world evolves.
On the evolution of education in the Age of the Web. Tyler Cowen, in Average Is Over, via The Atlantic:
It will become increasingly apparent how much of current education is driven by human weakness, namely the inability of most students to simply sit down and try to learn something on their own.
I'm curious whether we'll ever see a significant change in the number of students who can and do take the reins for themselves.
On the evolution of the Web. Jon Udell, in A Web of Agreements and Disagreements:
The web works as well as it does because we mostly agree on a set of tools and practices. But it evolves when we disagree, try different approaches, and test them against one another in a marketplace of ideas. Citizens of a web-literate planet should appreciate both the agreements and the disagreements.
Some disagreements are easier to appreciate after they fade into history.
Eventually a software project becomes a small amount of useful logic hidden among code that copies data between incompatible JSON libraries
Not all citizens of a web-literate planet appreciate disagreements between JSON libraries. Or Ruby gems.
On the evolution of start-ups. Rands, in The Old Guard:
... when [the Old Guard] say, "It feels off..." what they are poorly articulating is, "This process that you're building does not support one (or more) of the key values of the company."
I suspect the presence of incompatible JSON libraries means that our software no longer supports the key values of our company.
October 16, 2014 3:54 PM
For Programmers, There Is No "Normal Person" Feeling
I see this in the lab every week. One minute, my students sit peering at their monitors, their heads buried in their hands. They can't do anything right. The next minute, I hear shouts of exultation and turn to see them, arms thrust in the air, celebrating their latest victory over the Gods of Programming. Moments later I look up and see their heads again in their hands. They are despondent. "When will this madness end?"
Last week, I ran across a tweet from Christina Cacioppo that expresses nicely a feeling that has been vexing so many of my intro CS students this semester:
I still find programming odd, in part, because I'm either amazed by how brilliant or how idiotic I am. There's no normal-person feeling.
Christina is no beginner, and neither am I. Yet we know this feeling well. Most programmers do, because it's a natural part of tackling problems that challenge us. If we didn't bounce between feeling puzzlement and exultation, we wouldn't be tackling hard-enough problems.
What seems strange to my students, and even to programmers with years of experience, is that there doesn't seem to be a middle ground. It's up or down. The only time we feel like normal people is when we aren't programming at all. (Even then, I don't have many normal-person feelings, but that's probably just me.)
I've always been comfortable with this bipolarity, which is part of why I have always felt comfortable as a programmer. I don't know how much of this comfort is natural inclination -- a personality trait -- and how much of it is learned attitude. I am sure it's a mixture of both. I've always liked solving puzzles, which inspired me to struggle with them, which helped me get better struggling with them.
Part of the job in teaching beginners to program is to convince them that this is a habit they can learn. Whatever their natural inclination, persistence and practice will help them develop the stamina they need to stick with hard problems and the emotional balance they need to handle the oscillations between exultation and despondency.
I try to help my students see that persistence and practice are the answer to most questions involving missing skills or bad habits. A big part of helping them this is coaching and cheerleading, not teaching programming language syntax and computational concepts. Coaching and cheerleading are not always tasks that come naturally to computer science PhDs, who are often most comfortable with syntax and abstractions. As a result, many CS profs are uncomfortable performing them, even when that's what our students need most. How do we get better at performing them? Persistence and practice.
The "no normal-person feeling" feature of programming is an instance of a more general feature of doing science. Martin Schwartz, a microbiologist at the University of Virginia, wrote a marvelous one-page article called The importance of stupidity in scientific research that discusses this element of being a scientist. Here's a representative sentence:
One of the beautiful things about science is that it allows us to bumble along, getting it wrong time after time, and feel perfectly fine as long as we learn something each time.
Scientists get used to this feeling. My students can, too. I already see the resilience growing in many of them. After the moment of exultation passes following their latest conquest, they dive into the next task. I see a gleam in their eyes as they realize they have no idea what to do. It's time to bury their heads in their hands and think.
October 15, 2014 3:54 PM
Maybe We Just Need to Teach Better
Maybe We Just Need to Teach Better
A couple of weeks ago, I wrote Skills We Can Learn in response to a thread on the SIGCSE mailing list. Mark Guzdial has now written a series of posts in response to that thread, most recently Teaching Computer Science Better To Get Better Results. Here is one of the key paragraphs in his latest piece:
I watch my children taking CS classes, along with English, Chemistry, Physics, and Biology classes. In the CS classes, they code. In the other classes, they do on-line interactive exercises, they write papers, they use simulations, they solve problems by-hand. Back in CS, the only activity is coding with feedback. If we only have one technique for teaching, we shouldn't be surprised if it doesn't always work.
Mark then offers a reasonable hypothesis: We get poor results because we use ineffective teaching methods.
That's worthy of a new maxim of the sort found in my previous post: If things aren't going well in my course, it's probably my fault. Mark's hypothesis sounds more professional.
A skeptic might say that learning to program is like learning to speak a new human language, and when we learn new human languages we spend most of our time reading, writing, and speaking, and getting feedback from these activities. In an introductory programming course, the programming exercises are where students read, write, and get feedback. Isn't that enough?
For some students, yes, but not for all. This is also true in introductory foreign language courses, which is why teachers in those courses usually include games and other activities to engage the students and provide different kinds of feedback. Many of us do more than just programming exercises in computer science courses, too. In courses with theory and analysis, we give homework that asks students to solve problems, compute results, or give proofs for assertions about computation.
In my algorithms course, I open most days with a game. Students play the game for a while, and then we discuss strategies for playing the game well. I choose games whose playing strategies illustrate some algorithm design technique we are studying. This is a lot more fun than yet another Design an algorithm to... exercise. Some students seem to understand the ideas better, or at least differently, when they experience the ideas in a wider context.
I'm teaching our intro course right now, and over the last few weeks I have come to appreciate the paucity of different teaching techniques and methods used by a typical textbook. This is my first time to teach the course in ten years, and I'm creating a lot of my own materials from scratch. The quality and diversity of the materials are limited by my time and recent experience, with the result being... a lot of reading and writing of code.
What of the other kinds of activities that Mark mentions? Some code reading can be turned into problems that the students solve by hand. I have tried a couple of debugging exercises that students seemed to find useful. I'm only now beginning to see the ways in which those exercises succeeded and failed, as the students take on bigger tasks.
I can imagine all sorts of on-line interactive exercises and simulations that would help in this course. In particular, a visual simulator for various types of loops could help students see a program's repetitive behavior more immediately than watching the output of a simple program. Many of my students would likely benefit from a Bret Victor-like interactive document that exposes the internal working of, say, a for loop. Still others could use assistance with even simpler concepts, such as sequences of statements, assignment to variables, and choices.
In any case, I second Mark's calls to action. We need to find more and better methods for teaching CS topics. We need to find better ways to make proven methods available to CS instructors. Most importantly, we need to expect more of ourselves and demand more from our profession.
When things go poorly in my classroom, it's usually my fault.
October 14, 2014 2:22 PM
A Handy Guideline for Teaching Beginners
I was putting together a short exercise for my students to do in class today. "Maybe this is too difficult. Should I make it easier?"
If you ever ask yourself this question, there is only one answer.
When in doubt, make it simpler.
On the days when I trust its wisdom and worry that I've made things too easy to be interesting, I am usually surprised by how well things go. On the days when I get lazy, or a little cocky, and stick with something that caused me to wonder, there is usually very little surprise.
October 13, 2014 1:43 PM
Buckets, Tap Shoes, and Smaller Places
I was in St. Paul this weekend to visit my younger daughter for the first time since she started college six weeks ago. (It is hard to believe I dropped my older daughter off at school for the first time three years ago.)
Friday night, my daughter treated us to a performance by Buckets and Tap Shoes. The group blended dance, music, and seductive showmanship to create a show that kept me bouncing in rhythm for two hours. The dance and music were heavy on tap and drums, which let the performers play with rhythms. They also interacted with the crowd throughout the show, which set them up for an encore finale with twenty or more audience members on stage drumming, dancing, and generally into the rhythm. Impressive.
We like her school, and the Highland Park neighborhood is quite nice, but the Twin Cities are too big and busy for my tastes. I'm glad to live where I live.
October 06, 2014 4:02 PM
A New Programming Language Can Inspire Us
In A Fresh Look at Rust, Armin Ronacher tells us that some of what inspires him about Rust:
For me programming in Rust is pure joy. Yes I still don't agree with everything the language currently forces me to do but I can't say I have enjoyed programming that much in a long time. It gives me new ideas how to solve problems and I can't wait for the language to get stable.
Rust is inspiring for many reasons. The biggest reason I like it is because it's practical. I tried Haskell, I tried Erlang and neither of those languages spoke "I am a practical language" to me. I know there are many programmers that adore them, but they are not for me. Even if I could love those languages, other programmers would never do and that takes a lot of enjoyment away.
I enjoy reading personal blog entries from people excited by a new language, or newly excited by a language they are visiting again after a while away. I've only read Rust code, not written it, but I know just how Ronacher feels. These two paragraphs touch on several truths about how languages excite us:
- Programmers are often most inspired when a language shows them new ideas how to solve problems.
- Even if we love a language, we won't necessarily love every feature of the language.
- What inspires us is personal. Other people can be inspired by languages that do not excite us.
- Community matters.
Many programmers make a point of learning a new language periodically. When we do, we are often most struck by a language that teaches us new ways to think about problems and how to solve them. These are usually the languages that have the most teach us at the moment.
As Kevin Kelly says, progress sometimes demands that we let go of problems. We occasionally have to seek new problems, in order to be excited by new ways to answer them.
This all is very context-specific, other. How wonderful it is to live in a time with so many languages available to learn from. Let them all flourish, I say.
October 02, 2014 3:46 PM
Skills We Can Learn
In a thread on motivating students on the SIGCSE mailing list, a longtime CS prof and textbook author wrote:
Over the years, I have come to believe that those of us who can become successful programmers have different internal wiring than most in the population. We know you need problem solving, mathematical, and intellectual skills but beyond that you need to be persistent, diligent, patient, and willing to deal with failure and learn from it.
These are necessary skills, indeed. Many of our students come to us without these skills and struggle to learn how to think like a computer scientist. And without persistence, diligence, patience, and a willingness to deal with failure and learn from it, anyone will likely have a difficult time learning to program.
Over time, it's natural to begin to think that these attributes are prerequisites -- things a person must have before he or she can learn to write programs. But I think that's wrong.
As someone else pointed out in the thread, too many people believe that to succeed in certain disciplines, one must be gifted, to possess an inherent talent for doing that kind of thing. Science, math, and computer science fit firmly in that set of disciplines for most people. Carol Dweck has shown that having such a "fixed" mindset of this sort prevents many people from sticking with these disciplines when they hit challenges, or even trying to learn them in the first place.
The attitude expressed in the quote above is counterproductive for teachers, whose job it is to help students learn things even when the students don't think they can.
When I talk to my students, I acknowledge that, to succeed in CS, you need to be persistent, diligent, patient, and willing to deal with failure and learn from it. But I approach these attributes from a growth mindset:
Persistence, diligence, patience, and willingness to learn from failure are habits anyone can develop with practice. Students can develop these habits regardless of their natural gifts or their previous education.
Aristotle said that excellence is not an act, but a habit. So are most of the attributes we need to succeed in CS. They are habits, not traits we are born with or actions we take.
Donald Knuth once said that only about 2 per cent of the population "resonates" with programming the way he does. That may be true. But even if most of us will never be part of Knuth's 2%, we can all develop the habits we need to program at a basic level. And a lot more than 2% are capable of building successful careers in the discipline.