While posting my last entry, I realized that my blog gives the impression that ChiliPLoP'05 lasted only one day. Actually, it lasted from Tuesday evening through Friday's lunch. The reason I have not written more is that the conference kept me busy with the work I was there to do!
Our hot topic group had a productive three days. On Days 2 and 3, we continued with our work on the examples we began on Day 1, refining the code for use by students and discussing how to build assignments around them.
As the conference drew to its close on the last morning, our discussions turned to the broader vision of what a great new first course would be like. By the end of CS1, traditional curricula expose students to lots of complexity in terms of algorithmic patterns: booleans, selection, repetition, collections, and the like. We would like to create a course that does the same for object-oriented programming. Such a course would emphasize: objects, relationships among them, and communication. Concepts like delegation, containment, and substitution would take on prominent roles early in such a course.
Current textbooks that put objects front and center fail to take this essential step. For example, they may make a date class, but they don't seem to use Dates to then build more complex objects, such as weeks or calendars, or to let lots of date objects collaborate to solve an interesting problem. Most of the programming focus remains in implementing methods, using the familiar algorithmic patterns.
Our desire to do objects right early requires us to find examples for which the OO style is natural and accessible to beginners. Graphical and event-driven programs make it possible, even preferable, to use interesting objects in interesting ways early on, with no explicit flow of control. But what other domains are suitable for CS1, taking into account both the students' academic level and their expectations about the world of computers?
Our desire also means that we must frame compelling examples in an object-oriented way, rather than an algorithmic way. For instance, I can imagine all sorts of interesting ways to use the Google API examples I worked on last week to teach loops and collections, including external and internal iterators. But this can easily become a focus on algorithm instead of objects. We need to find ways to inject algorithmic patterns into solutions that are fundamentally based on objects, not the other way around.
The conference resulted in a strong start toward our goals. Now, our work goes on...
The problem about art is not finding more freedom,
it's about finding obstacles.
-- Richard Rogers
I started teaching introductory programming back in the fall of 1992. Within a year or so, I found myself drawn to a style of teaching that would eventually be called patterns. At the time, I spoke of 'patterns' and 'templates', and it took a while for me to realize that the power of patterns lay more in understanding the forces that shape a pattern as in the individual patterns themselves. But even in their rawest, most template-like form, simple patterns such as Guarded Linear Search were of great value to my students.
Back when I first starting talking about these ideas with my colleagues, one of them almost immediately expressed reservations. Teaching patterns too early, he argued, would limit students' freedom as they learned to write programs, and these limitations would stunt their development.
But my experience was exactly the opposite. Students told me that they felt more empowered, not less, but the pattern-directed style, and their code improved. One of the biggest fears students have is of the blank screen: They receive a programming assignment. They sit down in front of a computer, open a text editor, and ... then what? Most intro courses teach ways to think about problems and design solution, but they tend to be abstract guidelines. Even when students are able to apply them, they eventually reach the moment at which they have to write a line of code ... and then what?
The space of all possible programs that students can write overwhelms many novices. The most immediate value in knowing some programming patterns is that the patterns constrain the space to something more reasonable. If the problem deals with processing items in a collection, then students need only recognize that the problem is a search problem to focus in on a few standard patterns for solving such problems. And each pattern gave them concrete advice for writing actual code to implement the pattern -- along with some things to think about as they customized the code to their specific situation.
So, rather than limiting novice programmers, patterns freed them. They could now proceed with some confidence in the task of writing code.
But I think that patterns do more than help programmers become competent. I think that they help already competent programmers become creative.
You can't create unless you're willing to subordinate the creative impulse to the constriction of a form.
-- Anthony Burgess
Just as too much freedom can paralyze a novice with an overabundance of possibility, too much freedom can inhibit the competent programmer from creating a truly wonderful solution. Sticking with a form requires the programmer to think about resources and relationships in a way that unconstrained design spaces do not. This certainly seems to be the case in the arts, where writers, visual artists, and musicians use form as a vehicle for channeling their creative impulses.
Because I am an academic computer scientist, writing is a big part of my job, too. I learned the value of subordinating my creative impulse to the constriction of a form when I began to write patterns in the ways advocated with the patterns community. I've written patterns in the Gang-of-Four style, the PoSA style, the Beck form, and a modified Portland Form. When I first tried my hand at writing some patterns of knowledge-based systems, I *felt* constricted. But as I became familiar with the format I was using, I began to ask myself how best to express some idea that didn't fit obviously into the form. Often, I found that the reason my idea didn't fit into the form very well is that I didn't have a clear understanding of the idea itself! Holes in my written patterns usually indicated holes in my thinking about the software pattern. The pattern form guided me on the path to a better understanding of content that I thought I already knew well.
Constraining ourselves to a form is but one instance of a more general heuristic for creating. Sometimes, the annoying little problems we encounter when doing a task can play a similar role. I love this quote from Phillip Windley, reporting some of the lessons that 37signals learned building Basecamp:
Look at the problems and come up with creative solutions. Don't sweep them under the rug. Constraints are where creative solutions happen.
Constraints are where creative solutions happen.
Our first day at ChiliPLoP was a success. On our first evening in Carefree, my Hot Topic group decided to focus its energy on examples dealing with programs that interact over a network, when possible with services that provide large access to current or compelling data. We alternately worked individually and in pairs on programs that access the current time from the official clock of the US, interact with Google web services, process streaming ML data, and interact with other students via Rendezvous. In just one day, we wrote some simple programs that are within reach of students learning to program in a first CS course.
We kept each other honest with continuous devil's advocacy. In particular, we are sensitive to the fact that examples of this sort run the risk of scaring many CS1 instructors. They are nontraditional but, more, they carry the impression of being complex and "cutting edge", attributes that don't usually work in CS1. If the instructors don't know much about the Google API or Rendezvous, how can we expect students to get them?
We decided that we will have to engage this possibility actively. First, we resolved not to use the term "web services" when describing any of our examples, even little-w "web services", in order not to alarm folks before they have a chance to see the simplicity of the programs we create and the value they have for working with students.
Second, we know that we will have to be quite clear that learning about Rendezvous or the Google API is not the end goal of these examples. The goal is to help students learn how to write programs in an object-oriented language. We will need to package our examples with curricular materials that identify the programming elements and design ideas they best teach. This packaging is for instructors, not students, though as a result the students will benefit by encountering examples at the right point in their development as programmers.
I am again reminded that a big part of our job in the elementary patterns community is educating computer science faculty, as much or more so than educating students!
At the end of our day yesterday, we had a nice no-technology discussion out on the veranda of the conference center about our day's work. Devil's advocacy led us into a challenging and sometimes frustrating discussion about the role of "magic" in learning. Some in our group were concerned that the Rendezvous example will look too much like magic to the students, who write very simple objects that interact with very complex objects that we supply. Others argued that students working with objects in a more realistic context is a good thing and, besides, students see magic all the time when learning a language. Java's System.out.println() is serious magic -- bad magic, many of Java-in-CS1's critics would say. But let's be honest: Pascal's writeln() was serious magic, too. Ahh, those critics often say, it's simpler magic (no System.out abstraction) and besides, it's part of the base language. Hence the frustration for me in this discussion, and in so many like it.
If too much magic is a deal breaker, then I do not think we can we do compelling examples with our students. These days, compelling examples require rich context, and rich context early in the course requires some magical objects.
But I don't think magic is a deal breaker. The real issue is gratuitous magic versus essential magic. In Java,
is gratuitous magic. Interacting with powerful and interesting objects is essential magic. It is what object-oriented programming is all about! It's also what can make an example compelling to students raised in an era of instant messaging and Amazon and eBay. What we as instructors need to do is to build suitable boundaries around complexity so that students can explore without fear and ultimately open up the boxes and see that what's inside isn't magic at all but simply more complex examples of the same thing that students have been learning all along: powerful objects sending messages to one another.
Right now, we are all expanding on our examples from yesterday. Later, I hope that we have a chance to mine some of the elementary patterns that show up across our examples. We are at a PLoP conference after all!
A couple of things that occurred to me while running through the low mountain desert north of Carefree, Arizona, this morning:
A dead end isn't always a bad thing.
Sometimes, running to the dead end has its own benefits, even if only the joy of the running.
Running up big hills is worth the effort.
Of course, running up hills makes you stronger. It makes you stronger when running on level ground. It makes little hills seem like not so much. It teaches you that running up other big hills is doable.
Perhaps as important, though, is this: The view from the top of the hill can be stunning. You see the world differently up there.
Sometimes, you run to get from Point A to Point B, to accomplish a goal. Sometimes, you should just run.
These are true about computer programming, too, and many other things.
In my last blog, I discussed the search for fresh new examples for use in teaching an OO CS1 course. My LazyWeb request elicited many interesting suggestions, some of which have real promise. Thanks to all who have sent suggestions, and thanks for any others that might be on the way!
While simple graphical ball worlds make for fun toy examples, they don't seem as engaging to me as they did a few years back. As first demos, they are fine. But students these days often find them too simplistic. The graphics that they can reasonably create in the first course pale when compared to the programs they have seen and used. To use ball world, we need to provide infrastructure to support more realistic examples with less boilerplate code.
Strategy and memory games engage some students quite nicely. Among others, I have used Nim, Simon, and Mastermind. Mastermind has always been my favorite; it has so many wonderful variations and offers so many opportunities to capitalize on good OO design.
Games of all sorts seem to engage male students more than female students, which is a common point of conversation when discussing student retention and the diversity of computer science students. We need to use a broader and more interesting set of examples if we hope to attract and retain a more broader group of students. (More on whether this should be an explicit goal later.)
I think that this divide is about something much more important than just the interests of men and women. The real problem with games as our primary examples is that these examples are really about nothing of consequence. Wanting to work on such a problem depends almost solely on one's interest in programming for programming's sake. If students want to do something that matters, then these examples won't engage their interest.
This idea is at the core of our desire to create a new sort of CS 1 book. As one of my readers pointed out in an e-mail, most introductory programming instruction isn't about anything, either. It "simply marches through the features of whatever language is being used" at the time. The examples used are contrived to make the language feature usable -- not always even desirable, just usable.
Being about nothing worked for Seinfeld, but it's not the best way to help students learn -- at least not if that's all we offer them. It also limits the audience that we can hope to attract to computing.
So much of computer science instruction is about solutions and how to make them, but the solutions aren't to anything in particular. That appeals to folks who are already interested in the geeky side of programming. What about all those other folks who would make good computer scientists working on problems in other domains? Trying to create interesting problems around programming techniques and language features is a good idea, but it's backward.
Interesting problems come from real domains. I learned the same lesson when studying AI as a graduate student in the 1980s. We could build all the knowledge-based systems we wanted as toys to demonstrate our techniques, but no one cared. And besides, where was the knowledge to come from? For toy problems, we had to make it up, or act as our own "domain experts". But you know, building KBS was tougher when we had to work with real domain experts: tax accountants and chemical engineers, plant biologists and practicing farmers. The real problems we worked on with real domain experts exercised our techniques in ways we did not anticipate, helping us to build richer theories at the same time we were building programs that people really used. I thank my advisor for encouraging this mindset in our laboratory from its inception.
Real domain problems are more likely to motivate students and teachers. They offer rich interconnections with related problems and related domains. Some of these problems can be quite simple, which is a good thing for teaching beginning students. But many have the messy nature that makes interesting ideas matter.
At OOPSLA last year, Owen Astrachan was touting the new science of networks as a source of interesting problems for introductory CS instruction. The books Linked and Six Degrees provide a popular introduction to this area of current interest throughout academia and the world of the Web. Even the idea of the power law can draw students into this area. I recently asked students to write a simple program that included calculating the logarithm of word counts in a document, without saying anything about why. Several students stopped by, intrigued, and asked for more. When I told them a little about the power law and its role in analyzing documents and explaining phenomena in economics and the Web, they all expressed interest in digging deeper.
Other problems of this sort are becoming popular. We have started an undergraduate program in bioinformatics and have begun to explore ways to build early CS instruction around examples from that domain. The availability of large databases and APIs opens new doors, too. Google and Amazon have opened their databases to outside programmers. At last year's ITiCSE conference the invited talks all focused on the future of CS instruction by going back to a time in which computing research focused on applied problems.
If you've been reading here for a while, then you have read about the importance of context in learning before. A big part of Alan Kay's talks there focused on how students can learn about the beauty of computing through doing real science. His eToys project has students build simulations of physical phenomena that they can observe, and in doing so learn a lot about mathematics and computation. But this is a much bigger idea in Kay's work. If you haven't yet, read his Draper Prize talk, The Power Of The Context. It speaks with eloquence about how people have great ideas when they are immersed in an environment that stimulates thought and connections. Kay's article says a lot about how the working conditions in lab foster such an environment, and perhaps most importantly the people. In an instructional setting the teacher and fellow students define most of this part of the environment. Other people can be a part of the environment, too, through their ideas and creations -- see my article on Al Cullum and his catchphrase "a touch of greatness".
But the problems that we work on are also an indispensable element in the context that motivates people to do great work. In his Draper Prize talk, Kay speaks about how his erox PARC lab worked with educators, artists, and engineers on problems that mattered to them, along with all the messy distractions that those problems entail. Do you think that the PARC folks would have created as many interesting tools and ideas if they had been working "Hello, World" and other toy problems of their own invention? I don't.
Alan's vision in his OOPSLA talks was to create the computing equivalent of Frank Oppenheimer's Exploratorium -- 500 or more exciting examples with which young people could learn about math, science, computation, reading, and writing, all in context. With that many problems at hand, we wouldn't have to worry as much about finding a small handful of examples for use each semester, as every student would likely find something that attracted him or her, something to engage their minds deeply enough that they would learn math and science and computing just to be able to work on the problem that had grabbed a hold of them. The real problem engages the students, and its rich context makes learning something new worthwhile. Whenever the context of the problem is so messy that distractions inhibit learning, we as instructors have to create boundaries that keep the problem real but let the students focus on what matters.
Having students work on real problems offers advantages beyond motivation. Remember the problem of attracting and retaining a wider population of students? Real problems may help us there, too. We geeks may like programming for its own sake, but not everyone who could enrich our discipline does. Whatever the natural interests and abilities of students are, different kinds of people seem to different values that affect their choice of academic disciplines and jobs. This may explain some of the difficulty that computer science has attracting and retaining women. A study at the University of Michigan found that women tend to value working with and for people more than men, and that this value accounted at least in part for women tend to choose math and CS careers less frequently: they perceive that math and CS are less directly about people than some other disciplines, even in the sciences. If women do not have this perception, many of our CS1 and 2 courses would give it to them right away. But working on real problems from real domains might send a different signal: computing provides an opportunity to work with other people in more different ways than just about any other discipline!
I know that this is one of the reasons I so loved working in knowledge-based systems. I had a chance to work with interesting people from all over the spectrum of ideas: lawyers, accountants, scientists, practitioners, .... And in the meantime I had to study each new discipline in order to understand it well enough to help the people with whom I worked. It was a constant stream of new and interesting ideas!
I don't want you to think that no one is using real problems in their courses. Certainly a number of people are. For example, check out Mark Guzdial's media computation approach to introductory computing courses. Media computation -- programs that manipulate images, sounds, and video -- seems like a natural way to go for students of this generation. I think an example of this sort would make a great starting point for my group's work at ChiliPLoP next week. But Mark's project is one of only a few big projects aimed in this direction. If we are to reach an Exploratorium-like 650 great CS 1 examples, then we all need to pitch in.
One downside for instructors is that working with real problems requires a lot of work up front. If I want to use the science of networks or genomics as a my theme for a course, then I need to study the area myself well in advance of teaching the course. I have to design all new classroom examples -- and programming assignments, and exam questions. I will probably have to build support software to hide my students from gratuitous complexity in the domain and the programming tools that students use.
Another potential downside for someone at a small school is that an applied theme in your course may appeal to some students but not others, and your school can only teach one or a few sections of the course at any one time. This is where Alan Kay's idea of having a large laboratory of possibilities becomes so appealing.
This approach requires work, but my ChiliPLoP colleagues seem willing to take the plunge. I'll keep you posted on our efforts and results as they progress.
Some of my favorite colleagues and I will be getting together in a week or so for ChiliPLoP 2005, where we will continue to work on our longstanding project, to produce a different sort of textbook for the CS 1 course. We'd like to create a set of instructional units built around engaging and instructive applications. In a first course, these applications will have to be rather small, but we believe students can learn more and better about how to program when their code has a context.
In many ways, Mike Clancy's and Marcia Linn's classic Designing Pascal Solutions serves as my goal. Clancy and Linn did for structured programming and Pascal what I'd like for our work to do for object-oriented programming and Java (or whatever succeeds it). Their case studies focus on simple yet complete programs such as a calendar generator, a Roman numeral calculator, and a text processor, using them as the context in which students learn the basics of computation and Pascal syntax. Along the way, they also learn to something about how to write programs which is, in many ways, the central point of the course. This book, and its data structures follow-up, implement a wonderful teaching idea well. I think we can do this for OOP, and can use what we've learned about patterns in the intervening 15 years to do it in an especially effective way.
Such an approach requires that we identify and work out in some detail several such examples. The old examples worked great in a text-oriented world in which students' experience with computers was rather limited, but we can surely do better. Our students come to the university with broad experience interacting with computer systems. Cell phones, iPods, and TiVo are a part of the fabric of their lives. Besides, objects and languages like Java bring graphical apps, client-server apps, web apps, and other more sophisticated programs within reach.
A canonical first example for a graphical OOP introduction to programming is the ball world, a framework for simple programs in which balls and other graphical elements move about some simulated world, interacting in increasingly sophisticated ways. The folks at Brown and Duke have been developing this line of examples for a decade or more, and Tim Budd wrote a successful book aimed at students in a second or third course in which this is the first "real" Java program students see.
But ball world is tired, and besides it doesn't make much of a connection to the real world of computing these days. It might work fine to introduce students to the basics of Java graphics, but it needs serious work as an example that can both be used as early in CS 1 and engage many different students.
This is drifting dangerously toward a longer and different essay that I've been meaning to write for a while now, but I don't have the time this morning. That essay will have to wait until tomorrow. In the meantime, I'll leave you with a catchphrase that Owen Astrachan was touting at OOPSLA last fall: Problems are the thing. Owen's right.
Returning to the more immediate issue of ChiliPLoP 2005 and our Hot Topic, if you have an idea for a motivating example that might engage beginning programmers long enough for us to help them learn a bit about programming and objects, please pass it on. Maybe we can make it one of our working examples!
'Men are wise in proportion, not to their experience,
but to their capacity for experience.
-- George Bernard Shaw
Yesterday in my CS II course, my students and I discussed some of the possible designs for their current assignment and how the decisions each programmer makes will change the nature of the program each writes. Later in the day, I received an e-mail message from one of the students. It ended:
P.S. Got home today, and started lab over, got to the same spot as before in under 2 hours, code is much easier to read and look at! Thanks.
My immediate thought was, "This guy has what it takes."
When I encounter such students, I don't need to see their code to know that they will eventually become good software developers, if their interest in computing stays strong. They have the most important characteristic of any learner: the capacity for experience.
This idea seems to be a theme running through many of my own experiences and reading lately. First, I remember reading this piece by Johanna Rothman. It distinguishes "several years of experience" from "the same year of experience several times". Johanna's blog focuses on hiring technical people, and she suggests questions you can ask job applicants in order to decide which kind of person they are. A candidate question is "Tell me about the first time you did that kind of work."
People who know the difference between the same year of experience multiple times and multiple years of experience have answers to these questions. People who do the same thing year-in, year-out don't have good answers.
I see the same thing in college students. Some students would use Johanna's question as a springboard into an engaging conversation about what they learned in the process of that first time. We end up talking not only about the first time but many times since. Even in the conversation we both may end up learning something, as we complement one another's experiences with our own.
Other students look at me unknowingly. They are often the ones who are still hitting the delete key 67 times instead of having taken the time to learn dd in vi (ctrl-k or something similar for emacs devotees :-).
Then I re-read Malcolm Gladwell's The Physical Genius after running into Pragmatic Dave's short note on making mistakes. I first read Gladwell's article a few years ago when someone first introduced me to his writing, but this time time it struck me in my experiential theme. Not only do these physical geniuses prepare obsessively, they also share a deep capacity for recognizing their own mistakes and learning from them. Rather than hide their errors behind a wall of pride, they almost revel in having recognized them and overcome them. They use their experiences to create experience.
Dave quotes Gladwell quoting Charles Bosk, who had tried to find a way to distinguish good surgeons from the not so good:
In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, 'Gee, I haven't really had one,' or, 'I've had a couple of bad outcomes but they were due to things outside my control' - invariably those were the worst candidates. And the residents who said, 'I make mistakes all the time. There was this horrible thing that happened just yesterday and here's what it was.' They were the best. They had the ability to rethink everything that they'd done and imagine how they might have done it differently."
Johanna Rothman would probably agree with Bosk's approach.
Some folks don't seem to have the mindset of Bosk's successful surgeons, at least by the time they reach my classroom, or even when they reach the workplace. In that same CS II class yesterday, I sensed that a few of the students were uncomfortable with the notion that they themselves had to make these design decisions. What if they made the wrong choice? I suggested to them that none of the choices was really wrong, and that each would make some things easier and other things harder. Then I told them that, even if they came to rue their choice of an Object over a Vector, that's okay! They can rest assured that the alternative would have been rueful in another way, and besides they will have learned something quite useful along the way. That was no comfort at all to the students who aren't uncomfortable.
So much of what students learn in college courses isn't listed in the course catalog description. I hope I can help some of my students to learn new habits of mind in this regard. Developing a capacity for experience is more important than learning the habit of TDD.
Then again, software people with a capacity for experience seem to gather in places where practices like TDD become a focal point. Patterns. Pragmatic programming. XP. Agile software development. All grew out of folks reflecting on their successes and failures with humility and asking, "How can we do better?" The student who sent me that e-mail message will fit in quite nicely.
As I mentioned last week, a feature writer for the local newspaper recently interviewed me for an article on blogging. The article appears in today's paper, and the on-line version is already live. The article is a bit light, given how much we talked, but it probably reflects the fact that there are a lot more soap opera-like blogs out than technical ones. And the technical ones will have much less appeal to most of the Courier's readership.
The good news is that I don't sound like an idiot. If anything, I sound like a long-winded academic. (The sarcastic reader can decide which it's better to be.) The author quotes me accurately enough, though my second quote is missing its ending, I think.
I wonder if I'll see any hits from new readers in the Cedar Valley as a result... We have a few software developers in the area, so some may even find my blog interesting.
When I first learned that Mihaly Csikszentmihalyi (whose name is pronounced 'me-HI chick-SENT-me-hi') would be speaking here, I hoped that he might be able to help me to understand better the role of flow in learning and programming. These ideas have been on mind occasionally through experience with the Suzuki method of piano instruction and Alan Kay's comments on the same in his talks at OOPSLA. When I left the lecture room last night, I was a bit disappointed with the talk, but as time passes I find that its ideas have me thinking...
Csikszentmihalyi opened by explaining that his interest creativity began as a child in Hungary. Many of his family members were artists and lived rich lives, but most people he knew lived "fragile lives", all too sensitive to the vagaries of war and economy. He chose to study creative people to see how everyone can live a better life, a less fragile life, a beautiful life.
Through his studies, he came to distinguish "small c" creativity and "big C" Creativity. To some degree, we all are creative in the small-c way, doing things that enrich our own lives but do not receive recognition from the outside world. Big-c creativity is different -- it produces ideas that "push our species ahead". At first, the use of recognition to distinguish quality of creativity seemed incongruent, but I soon realized that creative ideas take on a different form when they move out into the world and mingle with the rest of a domain's knowledge and culture. Csikszentmihalyi came back to this nugget later in his talk.
Big-C creativity is rare. Defining it is impossible, because every definition seems to over- or underconstrain something essential to creativity from our own experience. But Csikszentmihalyi asserted that society values Creativity for its ability to transform people and cultures, and that it drives creative people to "pursue to completion" the creative act.
To support his claim of scarcity and to begin to expose the culture's role in recognizing creativity, Csikszentmihalyi presented some empirical studies on the relationship between individuals' contributions and their disciplines. The first was the so-called Lotka Curve. Alfred Lotka was an eminent biophysicist of the early 1900s. In the mid-1920s, he identified a pattern of publication in scientific journals. Roughly 60% of all people who publish publish only one journal article. The percentage of people who publish two articles is much smaller, and the percentage of people who publish more articles falls rapidly as the number of articles increases. This creates an L-shaped graph of the function mapping number of publications onto the percentage of contributors at that level.
The second was Price's Law. He referred not to the law from physics, which describes a model of gravitational collapse and the "strong cosmic censorship conjecture" (a great name!), but to another model of contribution: one-half of all contributions in any domain are made by the square root of all potential contributors. According to Csikszentmihalyi, Price derived his law from data in a large variety of domains.
I do not have citations to refereed publications on either of these models, so I'm at the speaker's mercy as to their accuracy. The implication is substantial: in any group, most people contribute little or nothing to the group. Perhaps that is stated too strongly as a generalization, because a single publication or a single piece of art can make a major contribution to the world, belying the creator's point on the Lotka Curve. But if these models mean what Csikszentmihalyi claims, culture and even narrower domains of discourse are driven forward by the work of only a few. I don't think that this will alarm too many people. It sounds just like the long tail and power law that dominates discussion of the web and social networks these days.
Finally Csikszentmihalyi got around to describing his own results. Foremost was this model of how creativity and ideas affect the world:
The culture transmits information to people. Some people are happy to keep it at that, to absorb knowledge and use it in their lives. These folks accept the status quo.
The creative person, though, has the idea that he can change the world. He produces a novelty and pushes it out for others see. Only a small percentage of folks do this, but the number is large enough that society can't pay attention to all of the novelties produce.
A field of discourse, such as an academic discipline or "the art world", selects some of the novelties as valuable and passes them onto the culture at large with a seal of approval. Thus the field acts as a gatekeeper. It consists of the critics and powerbrokers esteemed by the society.
When there doesn't seem to be enough creativity for rapid change in a domain, the problem is rarely with the production of sufficient ideas but in the field's narrow channel for recognizing enough important novelties. I suppose that it could also come back to a field's inability to accurately evaluate what is good and what isn't. The art world seems to go through phases of this sort with some regularity. How about the sciences?
Csikszentmihalyi has devoted much of his effort to identifying common characteristics in the personalities of creative individuals. The list of ten characteristics he shared with his audience had some predictable entries and some surprises to me:
I'm not surprised to see high energy, openness to new experience, ambition, passion, ... on the list. They are just what I expect in someone who changes the world. But Numbers 7, 8, and 10 seemed counterintuitive to me. But some reflection and further explanation made sense of them. For example, #7 is a simplification, on the notion that historically many of the biggest contributors of ideas and works of art to society have been men. And these creative men tend to have personality traits that society usually associates with women. This element works the other way, too. Major female contributors tend to have personality traits that society usually associates with men. So this element might more accurately be labeled outside society's gender expectations or somesuch.
(And before anyone feels the needs to rain flame down on me a lá the recent Larry Summers fiasco, please note that I recognize fully the role that socialization and and other social factors play in the documented history of male and female contributions to the world. I also know that it's just a generalization!)
Convergent thinking and conservatism also seemed out of place on the list, but they make sense when I consider Csikszentmihalyi's systemic model of the flow of contributions. In order to affect the world, one must ordinarily have one's idea vetted by the field's powerbrokers. Rebelliousness isn't usually the best means to that end. The creative person has to balance rule breaking with rule following. And convergence of thought with ideas in the broader culture increases the likelihood of new ideas being noticed and finding a natural home in others' minds. Ideas that are too novel or too different from what is expected are easy to admire and dismiss as unworkable.
This talk didn't deal all that much with Csikszentmihalyi's signature issue, flow, but he did close with a few remarks from folks he had studied. Creators seem to share a predilection to deep attention to their work and play. In such moments, the ordinary world drops beyond the scope of their awareness. He displayed a representative quote from poet Mark Strand:
The idea is to be so ... so saturated with it that there's no future or past, it's just an extended present in which you're, uh, making meaning. And dismantling meaning, and remaking it.
I'm guessing that every programmer hears that quote and smiles. We know the feeling--saturation, making meaning.
Csikszentmihalyi closed his talk with a couple of short remarks. The most interesting was to refute the common perception that Creative people are prone to living dissolute lives. On the contrary, the majority of the folks he has studied and interviewed have been married for all of their adult lives, have families, participate at their churches in in civic organizations. They have somehow come to balance "real life" with sustained episodes of flow. But, true to Personality Trait #10 on the list above, they all feel guilty about not having spent more time with their spouses and children!
(At this point, I had to leave the talk just as the question-and-answer session was beginning. I had to pick my daughters up from play rehearsal. :-)
This talk has led me to a few thoughts...
And, to the extent that we can stimulate an environment in which the creative moment can occur, you need to active, engaged, and aware. That is a major component of the success that we see in highly productive people.
With so many great books to read, now that I have seen Csikszentmihalyi speak, I doubt that I'll read "Flow" any time soon. But I think its ideas will continue to percolate in mind.
I was just interviewed by a feature writer for the local newspaper for an article on blogging. We talked about a wide range of issues, among them why I read blogs, why I write my blog, when and how I write, some of the technical issues of RSS, how I got started, and how others can get started reading and writing.
We discussed the fact that some people think blogs are going to change the world of journalism, while others just don't get the whole blogging thing. I had to admit that I don't see much appeal in the sort of stream-of-consciousness confessional blogging that one tends to find at places at LiveJournal -- even if I occasionally post more personal items myself. I don't think that blogs are going to replace conventional journalism, and to the extent that conventional journalism changes in the next few years I think blogging will just be one instance of a larger cultural phenomenon at the root of the change.
But blogging does lower the barrier for people who think they have something to say to reach out and say it. I likened such blogs to the articles that two UNI professors write for the Sunday issue of the local paper. Their articles provide them with a way to write about issues in their technical domain (popular culture and economics, respectively) for a wider and less technical audience. My blog doesn't reach that broad an audience -- yet :-) -- but I do reach a wider audience than my courses and published articles can reach. And I am able to write articles about topics and their intersection that would be difficult or impossible to publish in an academic journal. For me, the real value in reading and writing blogs lies in the intellectual community it creates. Reflective professionals and otherwise interesting people share what they learn as they learn, and we all grow richer in the process. Sometimes that stray idea would make great dinner conversation makes for a great blog article -- and folks who would never have a chance to dine together can have a conversation.
The interview was fun for me, in much the same way as writing this blog can be: it caused me to formulate succinct answers to questions just under the surface of my consciousness. I hope that my answers make sense to the newspaper's readership. I also confess to a small bit of hope that I don't sound like a nutcase in print...
The reporter was well-prepared for the interview. She had a broad set of questions to ask and did a good job of following my answers onto other interesting questions. Besides, she complimented me for being an articulate interview, so she must have good taste and a keen mind!
Update: The feature will run in next Monday's issue, March 7. With any luck it will hit the on-line version of the paper, too.