Knowing and Doing

The little things I have left to learn... Twice today I encountered something about Java that I didn't know.

First: a colleague had a piece of code with three variables typed as bytes:

piecesRemaining = piecesAtStart - piecesTaken;

The compiler complained about a loss of precision. When he cast the righthand side of the expression to byte, everything worked fine:

piecesRemaining = (byte) (piecesAtStart - piecesTaken);

So off I trudge to the Java Language Reference, where on Page 27 I find:

Java performs all integer arithmetic using int or long operations. A value that is of type byte, short, or char is widened to an int or a long before the arithmetic operation is performed.

So your RHS value are upcast to ints for the subtraction, resulting in a downcast on assignment. But why does Java work this way? Any ideas?

Second: I'm teaching an undergraduate algorithms course this year for the first time in a long while, and I often find myself whipping up a quick program in Scheme or Java to demonstrate some algorithms we've designed in class. This afternoon I was implementing a brute-force algorithm for the old Gas Station Problem:

A cyclic road contains n gas stations placed at various points along the route. Each station has some number of gallons of gas available. Some stations have more gas than necessary to get to the next station, but other stations do not have enough gas to get to the next station. However, the total amount of gas at the n stations is exactly enough to carry a car around the route exactly once.

Your task: Find a station at which a driver can begin with an empty tank and drive all the way around the road without ever running out of gas.

The input to your algorithm is a list of n integers, one for each station. The ith integer indicates the number of miles a car can travel on the gas available at the ith station.

For simplicity, let's assume that stations are 10 miles apart. This means that the sum of the n integers will be exactly 10n.

The output of your algorithm should be the index of the station at which the driver should begin.

Our algorithm looked like this:

    for i ← 1 to n do
        tank ← 0
        for j ← i to ((i + n) mod n) do
            tank := tank + gas[j] - 10
            if tank < 0 then next i
        return i

How to do that next i thing? I don't know. So off again I go to the language reference to learn about labels and the continue statement. Now, to be honest, I knew about both of these, but I had never used them together or even thought to do so. But it works:

    outer:
    for ( int i = 0; i < gas.length; i++ )
    {
        tank = 0;
        for ( int j = i; j < i + gas.length; j++ )
        {
            tank = tank + gas[j % gas.length] - 10;
            if ( tank < 0 )
                continue outer;
        }
        return i;
     }

Some days I have major epiphanies, but more often I learn some little nugget that fills an unexpected hole in the web of my knowledge. The Java gurus among you are probably thinking, "He really didn't know that? Sheesh..."

Neither one of these Java nuggets is earth-shaking, just the sort of details I only learn when I need to use them in program for the first time. I suppose I could study the Java Language Reference in my free time, but I don't have the sort of job for which that sounds attractive. (Is there such a job?)

I've been following the development of Laurent Bossavit's software development dojo. He wrote about the idea in his blog a few times last year and then created a separate blog for it at this month at http://bossavit.com/dojo/.

The most recent article there speculates about programming as a performance art. It seems that the guys in the dojo have been presenting their code to one another and doing some of the programming live in front of the group. The experience has caused the author to re-think his artistic sense of programming:

Had I to choose earlier an art form which I felt connected to the act of programming, I would have picked book writing without hesitation. Something static, written at some time, read at another. Few dojo sessions later, I am not so positive anymore. I speculate the act of programming is also about the here and the now: how you currently live through the problem up to a satisfying conclusion, and how I feel engaged, watching your sharing techniques and insights. No cathartic experience so far -- hold your horses, this is sill embryonic stage -- although this could become a personal quest.

I feel a kinship here after the first three week of my CS II class, in which my students and I have been "gang programming" Ron Jeffries's bowling game using TDD. I've spent very little time expounding ex cathedra; most of my remarks have been made in the flow of programming, with only an occasional impromptu mini-lecture of a few minutes. If you know me, you probably don't think of me as a natural performer, but I've felt myself slipping into the gentle drama of programming. New requirements puzzle us, then worry us. A test fails. Programming ideas compete for attention. Code grows and shrinks. Green bar. Relief.

I hope that most of the students in the class are getting a sense of what it's like to make software. I also hope that they are enjoying the low drama of course.

My recent experience has brought to mind my favorite article on this topic, Bill Wake's Programming as Performance Art. He tells of seeing a particularly stirring performance by Kent Beck and Jim Newkirk:

They tackled the chestnut "Sieve of Eratosthenes." The 4-hand arrangement worked well, and let us see not only "programmer against complexity" but also "programmer against self" (when they started to make mistakes) and "programmer against programmer" (when they resolved their differences). The audience appreciated the show, but we should have applauded more enthusiastically.

I don't know what I'd do if my students ever applauded. But even if they never do, I like the feel of our live programming sessions. We'll see how effective they are as learning episodes as the semester progresses.

Brian Button recently posted a long blog entry on his extreme refactoring of the video store class from Martin Fowler's Refactoring. Brian "turned [his] refactoring knob up to about 12" to see what would happen. The result was extreme, indeed: no duplication, even in loops, and methods of one line only. He concluded, "I'm not sure that I would ever go this far in real life, but it is nice to know that I could."

Turning the knobs up in this way is a great way to learn something new or to plumb for deeper understanding of something you already know. A few months ago, I wrote of a similar approach to deepening one's understanding off polymorphism and dynamic dispatch via a simple etude: Write a particular program with a budget of n if-statements or less, for some small value of n. As n approaches 0, most programmers -- especially folks for whom procedural thinking is still the first line of attack -- find this exercise increasingly challenging.

Back at ChiliPLoP 2003, we had a neat discussion along these lines. We were working with some ideas from Karel the Robot, and someone suggested that certain if-statements are next to impossible to get rid of. For example, How can we avoid this if?

     public class RedFollowingRobot
     {
         public void move()
         {
             if (nextSquare().isRed())
                 super.move();
         }
     }

     public class Square
     {
         public boolean isRed()
         {
             ...
         }
     }

But it's possible... Joe Bergin suggested a solution using the Strategy pattern, and I offered a solution using simple dynamic dispatch. You can see our solutions at this wiki page. Like Brian said in his article, I'm not sure that I would ever go this far in real life, but it is nice to know that I could. This is the essence of the powerful Three Bears pattern: Often, in taking an idea too far, we learn best the bounds of its application.

Joe and I like this idea so much that we are teaching a workshop based on it, called The Polymorphism Challenge (see #33 there) at SIGCSE next month. We hope that spending a few hours doing "extreme polymorphism" will help some CS educators solidify their OO thinking skills and get away from the procedural way of thinking that is for many of them the way they see all computational problems. If you have any procedural code that you think simply must use a bunch of if-statements, send it to me, and Joe and I will see if it makes a good exercise for our workshop!

Back in October, I signed on for a second year as program chair for the OOPSLA Educators Symposium. Last year's symposium went well, with Alan Kay's keynote setting an inspirational mood for the symposium and conference, and I welcomed the chance to help put together another useful symposium for OO eductaors. Besides, the chance to work with Ralph Johnson and Dick Gabriel on their vision for an evolving OOPSLA was too much to pass up.

The calls for submissions to OOPSLA 2005 are available on-line now. All of the traditional options are available again, but what's really exciting are the new tracks: Essays, Lightning Talks, Software Studies, and FilmFest. Essays and Lightning Talks provide a new way to start serious conversations about programming, languages, systems, and applications, short of the academic research papers found in the usual technical program. I think the Software Studies track will open a new avenue in the empirical study of programs and their design. Check these CFPs out.

Of course, I strongly encourage all of you folks who teach OOP to consider submitting a paper, panel proposal, or nifty assignment to the Educators Symposium. As much as software development, teaching well depends on folks sharing successful techniques, results of experiments, and patterns of instructional materials.

This year, the symposium is honored to have Ward Cunningham as our keynote speaker. As reported here, Ward spoke at last year's OOPSLA. I love Ward's approach to programming, people, and tools. "OOPSLA is about programming on the edge, doing practical things better than most." "Be receptive to discovery." The symposium's program committee is looking forward to Ward sharing his perspective with educators.

If you've been to OOPSLA before, you know how valuable this conference can be to your professinal development. If not, ask someone who has been, or trust me and try it yourself. You won't be disappointed.

On his dinner conversation mailing list, Rich Pattis recently recommended the PBS movie A Touch of Greatness, about the teacher Albert Cullum. After attempting a career as a stage actor, Cullum began teaching in an elementary school in the late 1940s. He used poetry and drama as integral parts of his classroom, where children were encouraged to learn through productive work, not by listening to him. He believed that children have a natural affinity for great ideas and so introduced them to classic literature and real science immediately.

I missed the PBS showing of the film and may not get around to seeing it any time soon, so I grabbed a couple of his books from the library. The book that explains his teaching approach best looks to be Push Back the Desks. I just started it last night. Over the weekend, though, I read his children's-book-for-adults, The Geranium on the Window Sill Just Died But teacher Went Right On. I call it that because it is written just like a book for kindergarteners (one page of picture for each partial page of text, written with short sentences in a young student's voice) but is clearly aimed at adults. Indeed, the book is "dedicated to all those grownups who, as children, died in the arms of compulsory education".

Cullum clearly thinks that education is something quite different from what usually goes on in our schoolrooms. (Does that sound familiar?) He has a point. Though I've certainly thought a lot about the shortcomings of compulsory education -- especially since my daughters reached school age, I'd never thought about all the little ways in which school can dehumanize and demotivate the wonderful little minds that our children have.

Two passages from the book really struck a chord with me. In the first, a small child asks the teacher if she likes his picture of a cherry tree. The students has colored the cherries red and the leaves green, going against the instructions. "But, teacher, don't you see my rainbow? Don't you see all the colors? Don't you see me?"

The second comes from a student who has learned that he is not good at anything in school:

I was good at everything
--honest, everything!--
until I started being here with you.
I was good at laughing,
playing dead,
being king!
Yeah, I was good at everything!
But now I'm only good at everything
on Saturdays and Sundays...

What a deep feeling of resignation this child must feel to find that what matters to him doesn't matter, and that he isn't good at what matters. This is what we tell students when we place the focus on what they don't know rather than on what more is out there. When we tell them that their own identity is less important than our vision of who they should be.

Don't get me wrong. I don't believe in the Noble Savage theory about children, even children as learners. I don't think that a child's self-esteem can be made the centerpiece of all education. The child who colored the cherry tree backwards needs to learn to follow instruction. To suggest that this isn't an important skill to learn in school is to undermine an essential role in learning and thinking. And I don't believe that the second child was good at everything before he came to school. He may not have been good at much. But he felt like he controlled his enjoyment of the universe, at least in ways that mattered to him. He needs to learn that there is more to life than just laughing, playing dead, and being king. There are even times and places when those things aren't very important.

But he doesn't need to learn that those things don't matter. And he doesn't need to learn that individuality isn't important. He simply needs to learn that the world is even bigger than his wonderful little mind knows just yet, and that he can do more and better things in this big world. Education is about expanding the child's mind, not limiting it. It should build on who the child is, not who the teacher is. It should increase the wonder, not extinguish it.

Being this sort of teacher requires that most of us unlearn a lot of habits learned by example. Fortunately, most of us have had at least one teacher who inspired us in the ways Cullum suggests. I can think of many such teachers throughout my many years of education (Mrs. Brand, Mrs. Bell, Mr. Zemelko, Mr. Rickett, Mr. Smith, Dr. McGrath, and Dr. Stockman, to name a few). Even still, other habits formed -- and die hard, if at all, and only then after persevering. This is one of those situations in which I have some idea of what the right thing to do is, even if I don't do it very well yet.

I recently learned that Mihaly Csikszentmihalyi will be visit my campus for several talks in early March. Csikszentmihalyi (whose name is pronounced 'me-HI chick-SENT-me-hi') is well known for his theory of flow and its role in creativity and learning. Long ago I read some of Csikszentmihalyi's work, though I've never read the bestseller that made his name, Flow: The Psychology of Optimal Experience. Maybe now is the time.

Throughout his career, Csikszentmihalyi has studied the psychology of the creative individual: What characteristics are common to creative individual? How do creative people create? His talks here, though, will focus on the context in which creative individuals thrive. His main talk will describe how to create the sort of environment that must exist in order for a creative individual to contribute most effectively. His other talks will focus on specific contexts: How can educators "design curricula that capitalize on the human need to experience flow?" How work can contribute to well-being, and how can managers and employees create the right sort of workplace?

We agile folks often speak of "rhythm" and how TDD and refactoring can create a highly productive flow. And, while I've often heard critics say that P limits the individuality of developers, I've always thought that agile methods can unleash creativity. I'm curious to hear what Csikszentmihalyi has to say about flow and how we can create environments that support and nurture it, both for software development and for learning. You may recall an earlier discussion here about flow in learning, inspired by the Suzuki method of instruction and by Alan Kay's talks at OOPSLA. I think Csikszentmihalyi can help me to understand these ideas better.

Before leaving for the weekend, two quotes from blog reading today. Both are about the life of the mind.

From Uncertain Principles:

And, you know, in a certain sense, that's the whole key to being a scientist. It's not so much a matter of training, as a habit of mind. It's a willingness to poke randomly at a selection of buttons on somebody else's camera, in hopes that it might shed some light on the problem.

It's a habit that's all too easy to fall out of, too. It's easy to start relying on colleagues and technicians and reference works for information, and stop poking at things on your own.

From Electron Blue:

Books are patient, books are kind. They stay up with you all night and never complain that you are taking up too much of their time. They are never too busy to help you. They don't complain about being insulted and they rarely (if they are well-written and helpful books, that is) make you feel belittled or stupid. A book will not condescend or laugh at me because I am doing the most basic things over again. And you can work with a book at your own pace. [...] I once said to a Live Physicist that I am learning physics one electron at a time. He replied that this would mean that the time-span of my learning physics would exceed the projected life-span of the entire universe. Well, it may indeed take me that long to get to any kind of advanced physics. But I might as well start where I am, and keep going.

I took a leap of faith this week.

I teach our second course, CS II. It comes between an intro course in which students learn a little bit about Java and a little bit about objects, and a traditional data structures course using Ada95. The purpose of CS II is to give students a deeper grounding in Java and object-oriented programming.

The first thing I did on our first day of class was to write code. The first line of code I wrote was a test. The next thing I did was try to compile it, which failed, so I wrote the code to make it compile. Then I ran the test in JUnit and watched it fail. Then we wrote the code to make it pass.

And then we did it again, and again, and again.

I've long emphasized various agile practices in my courses, even as early as CS II, especially short iterations and refactoring. In recent semesters I've encouraged it more and more. Soon after fall semester ended, I decided to cross the rubicon, so to speak. Let tests drive all of our code. Let students feel agile development from all class and lab work.

Day 1 went well. We "gang-programmed", with students helping me to order requirements, write tests, find typos, and think through application logic. The students responded well to the unexpected overhead of JUnit. Coming out of the first course, they aren't used to non-java.* or extra "stuff".

In our second session, a lab class, students installed JUnit in their own accounts and wrote their first Java code of the semester: a JUnit test against the app we built in Day 1.

Oh, the app? Ron Jeffries' BowlingGame etude. It had just enough complexity to challenge students but not enough to pull too much of their attention away from the strange and wonderful new way we were building the program.

Next time, we'll add a couple of requirements that lead us to factor out a Frame, allowing us to see refactoring and how tests support changing their code.

I'm excited even as I'm a little on edge. New things in the classroom do that to me.

Some days my run just seems hard. I was planning a fast eight-mile workout this morning, but after three miles I found myself slowing down. I did manage a couple more fast miles, my sixth and eighth, but I didn't feel fast.

Then I checked my watch. 55 minutes, 56 seconds. Wow. That's just what I had hoped for. Now I feel guilty for having felt slow.

Winter offers a different sort of running. I'm not training for any particular race, so running 35 miles a week or so for fun and to maintain fitness seems like the right thing to do. But this winter I've fallen into something of a plan: get faster. Between the ice we've had on the roads, a foot of snow on the trails, and this morning's -7 degrees outside, I've run on the indoor track more than usual the last few weeks. And I always run faster on the track. The result has been an increase in speed.

If I can get faster over 35 miles a week this winter, maybe I can stretch the speed out over the longer miles I'll do next spring and summer. As I mentioned earlier, I'd love to make 8:00 miles feel like a walk in the park. A "slow" eight miles in 56:00 is a good start.

My first musical recommendation here has a computer programming twist. Eternal Flame is the first song I've ever heard that talks about both assembly language programming and Lisp programming, Even if you don't like folk music all that much, listen for a little while... It will confirm what you've always known deep in your heart: God programs in Lisp.

You can find other songs with technology themes at The Virtual Filksing.

(Via Jefferson Provost. Jefferson, if you ever record a rock version of Eternal Flame, please let me know!)

I've been busy with the first week of classes and some duties with conferences. But I wanted to share a couple of ideas that have been rolling around my mind lately.

From Ward Cunningham

There are a lot of ideas, but really good ideas are hard to snatch because they look so humble when you first see them. You expect the solution to be beautifully complex and a good solution is pretty plain until you see how that plainness plays in a complicated way to make something better than you could get in your head all at once.

"Humble ideas". Beauty often lies in how simple things interact with one another.

(I heard this in an interview Ward gave to TheServerSide.NET. You should watch it for yourself. Lots of great stuff there.)

From Kent Beck

Learning to listen empathically is the simplest thing I have control over that might change how others respond to me.

This statement hits me square in a personal weakness. I can be a good listener, but I'm not reliably a good listener. And inconsistency has an especially deleterious effect on how people come to feel about a person.

(I saw this quote on the XP discussion list.)

Brian Marick just blogged on Joel Spolsky's Advice for Computer Science College Students. I had the beginnings of an entry on Joel's stuff sitting in my "to blog" folder, but was planning to put it off until another day. (Hey, this is the last Thursday I'll be able to go home early for sixteen weeks...) But now I feel like saying something.

Brian's entry points that Joel's advice reflects a change in the world of programming from back when we old fogies studied computer science in school: C now counts as close enough to the hardware to be where students should learn how to write efficient programs. (Brian has more to say. Read it.)

I began to think again about Joel's advice when I read the article linked above, but it wasn't the first time I'd thought about it. In fact, I had a strong sense of deja vu. I looked back and found another article by Joel, on leaky abstractions, and then another, called Back to Basics. There is is a long-term theme running through Joel's articles, that programmers must understand both the abstractions they deal in and how these abstractions are implemented. In some ways, his repeated references to C are mostly pragmatic; C is the lingua franca at the lowest level of software development, even -- Brian mentions -- for those of us who prefer to traffic in Ruby, Smalltalk, Perl or Python. But C isn't the key idea Joel is making. I think that this, from the leaky abstractions, article, is [emphasis added]:

The law of leaky abstractions means that whenever somebody comes up with a wizzy new ... tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." [...] tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning.

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

Programming has always been hard, but it gets harder when we move up a level in abstraction, because now we have to worry about the interactions between the levels. Joel's article argues us that it's impossible to create an abstraction that doesn't leak. I'm not sure I willing to believe it's impossible just yet, but I do believe that it's close enough for us to act as if it is.

That said, Brian's history lesson offers some hope that that the difficulty of programming isn't growing harder at an increasing rate, because sometimes what counts as the lowest level rises. C compilers really are good enough these days that we don't have to learn assembly in order to appreciate what's happening at the machine level. Or do we?

Oh, and I second Brian's recommendation to read Joel's Advice for Computer Science College Students. He may just be one of those old fogies "apt to say goofy, antediluvian things", but I think he's spot on with his seven suggestions (even though I think a few of his reasons are goofy). And that includes the one about microeconomics!

When I'm out shopping for any big-ticket item, such as a car, I am notoriously slow to pull the trigger. I can be just as slow on even relatively inexpensive items like stereos, or snack food. My wife long ago learned to give me time, to walk off and let me stew a bit, before putting any pressure on me to make a decision. But she also learned that without such pressure I may never decide to buy or not. Talk about the Halting Problem.

What's the cause of my shopping behavior? Perhaps I'm prone to regret and am trying to protect myself from that gnawing feeling that I've made the wrong choice. Having even a few alternatives makes my choice difficult. (To be honest, I think I worry about feeling regret at having spent the money at all, which just makes me cheap. :-)

Difficulty making choices has been a thread over on the XP discussion list recently. Jason Yip read Barry Schwartz's April 2004 Scientific American article The Tyranny of Choice, which is based on his popular book The Paradox of Choice. Schwartz argues that there exists something of a Laffer curve at work when it comes to the psychology of decision making. Having few or no choices gives people little opportunity to control their destinies, which often results in being disappointed with how things turn out. Having many choices gives people a feeling of control but increases the probability of making the wrong choice, which leads to regret. Schwartz points out that regret tends to make people more unhappy than disappointment. From this, he concludes that having too many alternatives is actually worse for people than having too few.

Jason raised Schwartz's thesis in the context of customer choice in XP, brought on by an earlier thread about optional scope contracts. He asked if anyone had observed the "tyranny of choice" phenomenon manifest itself as resistance to more flexible approaches to defining project scope. We can frame the question even more broadly, as XP offers many choices in the release and iteration planning phases of a project that customers may not be used to. The resulting thread of discussion offered several interesting takes on this idea. Check it out.

When I'm doing XP, my customers face a somewhat different situation than I do when I'm buying a car. Customers tend to make their choices as part of a longer-term relationship, and the new choices P gives them are more about ordering the steps of the project than selecting only one from a set of alternatives. If they make a choice they regret, they will have a chance to re-prioritize requirements when helping to plan the next release. As a result, their regret will tend to be short-lived and more about short-term opportunity cost. (Mike Feathers made a similar argument on the discussion list.)

Of course, when developing software in a more traditional way, someone is making all these choices, though often it is the technical team. You'd think that customers would be no worse off making their own choices, even if they come to regret them, than by having some programmer make the decision in his cubicle one night. But that's the vexing part of Schwartz's thesis: They feel worse off in regret at their decision than they do in disappointment at the programmer's.

Knowing this, agile developers can play a valid role in helping their customers make choices. When they see a customer having difficulty setting priorities, they can inject some of their professional experience into the mix. Telling customers how past projects have gone may help them set a priority for the current release. Reminding them that they will have a chance to guide the project's course again at the next release or iteration may help them avoid paralysis motivated by fear of regret.

Some folks on the XP list offered some fun little strategies for helping break a deadlock in decision making. For example, if the customer says that all features are equally important, try selecting what seems to you to be the least valuable feature as the first one to implement. Sometimes, that's enough of a push to get the customer to think he can do a better job than you and so choose. I'm guessing that it's especially important to manage expectations in this scenario -- you don't want the customer to think you tricked him into making a choice he ultimately regrets, because then he'll be saddled not only with regret but also a distrust of you. And trust is essential to a good working relationship, especially in an agile approach.

For me, this brings to mind my younger daughter. Since she was a toddler, she has generally had trouble deciding, whether the choice is among alternatives for dessert, or outfits to where, or whether to ride home in the car with mommy or daddy. (Like many other families, we often end up in the same with both cars!) Instinctively, I've always tried to reassure her that her decision isn't the Final Answer, that if she later wishes she'd chosen ice cream for dessert, well then, we can just have ice cream tomorrow. That hasn't always seemed to help, at least not with the choice at hand. But I think that it's a good way to approach the situation: don't put undue pressure on her, and help calm her fears -- whether of regret or of disappointing me, which sometimes seems to be a factor in her decisions that I didn't expect. Building a relationship in which she can trust me is the best I can hope for in helping her learn to choose. And, as she's gotten older, she has become a more confident decision maker.

Back to software: Ultimately, I think that the "paradox of choice" phenomenon is more a case for agile methods than a case against them. It underscores one of the great strengths of the agile approaches: an attitude toward job and customer based in respect, trust, and communication. When we value these ahead of hard-and-fast rules and ahead of "the process", we are able to adjust our approach to the particulars of the customer and the current project.

One of my goals this year is to not let paper bury me. So when the latest issue of Communications of the ACM hit my doorstep, I decided to deal with it in real-time. One article grabbed my attention for its protagonists: David Kestenbaum's "The Challenges of IDC: What Have We Learned From Our Past?", which is an excerpt of a panel at IDC 2004 that included Seymour Papert, Marvin Minsky, and Alan Kay.

Someone in the audience asked these pioneers of interaction design for children to comment on how their ideas could be framed in terms of "people's everyday realities", because people understand things better when you express them in terms of everyday experiences. I think all three responses have something to teach us about teaching, even at the university level. (Emphasis added by me.)

Papert:

You learn things better when they are connected with things you are passionate about. Connecting math to things that you don't care about doesn't help even if they belong to everyday life. ... What counts to you is your mental world of interests, dreams, and fantasies, which are often very far removed from everyday life. The key educational task is to make connections between powerful ideas and passionate interests...

Minsky:

The most important thing in learning is copying how other people think. I don't think learning by doing really gets one to emulate how other people think. ... We need a cultural situation where every child has an adult friend whom they can emulate. And communicate their ways of thinking to the child. Do something that gets each child to spend a few hours a month with someone worth copying. What we do now is to take a six year old and send him in a room full of six year olds. The result is that every person grows up with the cognitive capability of a five year old.

Kay:

I completely agree. I go to a music camp in the summer. What you see there are people with different abilities playing in the presence of master players. The camp doesn't accept coaches that won't play in the concert. Imagine a fifth-grade teacher assigning a composition and actually writing one herself. Shocking! What teachers do is broadcast in every way possible that "I'm not interested in this at all because I don't do it." I think it's unthinkable to teach six year olds to be six year olds. You need to have these models. It's like grad school. You go there to find professors that are more like you'd like to be and try to understand the way they think.

These answers embody two key ideas, one I'm conscious of most of the time and one that challenges me to do better:

1. Students prefer to learn from teachers who do the thing they teach. A programming teacher who doesn't program will lose students' attention as soon as he reveals through attitude or action that he doesn't care enough about the stuff to actually write programs himself. Besides, a programming teacher who doesn't program will almost by necessity be teaching programming out of a book, which isn't where the interesting part of programming happens!

2. Students learn from their passions, not from any old connection to the "real world". I suppose I know this, but it's easy for me as an instructor to make a connection to some real-world scenario -- even a good one -- only to find students nonplussed. Usually, I've made a connection to one of my passions. The key is to connect to *their* passions. But that's much harder! Not to mention the fact that each student's passion is unique to her life and situation. This makes all the more important what Alan Kay said at OOPSLA about the power of 650 examples.

In at least one respect, getting better at teaching software development is no different from getting better at software development itself: It requires constant attention to practice and a willingness to change practice. And in the case of Alan's 650 examples, it requires teamwork.

Happy New Year!

I've run into the same idea twice in the last couple of weeks, in two different guises. I take that as a hint from the universe that I should be thinking about this as I prepare for the upcoming semester. The idea is: Name it.

First, at a public event during Advent, a friend was talking about how to raise strong, self-aware children. She said, "You know when your children do something good. Name it for them." Children should know that what they are doing has a name. Names are powerful for thinking and for communication. When an act has a name, the act *means* something.

Then I was ran across a column by Ron Rolheiser that comes at the issue from the other side, from where our feeling doesn't seem as good. The article is called Naming Our Restlessness and talks about how he felt after entering his religious order as a young man of 17. He was restless and wondered if that was a sign that he should be doing something else. But then someone told him that he was merely restless.

His simple, honest naming of what we were feeling introduced us to ourselves. We were still restless, but now we felt better, normal, and healthy again. A symptom suffers less when it knows where it belongs.

Often, people can better accept their condition when it has a name. Knowing that what they feel is normal, normal enough to have a name and be a part of the normal conversation, frees a person from the fear of not knowing what's wrong with them. Sometimes, there's nothing wrong with you! And even when there is, when the name tells us that something horrible is wrong, even then a name carries great power. Now we know what is wrong. If there is something we can do to fix the problem, we have to know what the problem is. And even when there is nothing we can do to fix the problem, yes, even then, a name can bring peace. "Now I know."

What does this mean for teaching? Name when students do something good. If they discover a pattern, tell them the name. When they adopt a practice that makes them better programmers, tell them the name of the practice. If they do something that isn't so good, or when they are uneasy about something in the course, name that, too, so that they can go about the business of figuring out what to do next. And help them figure it out!

I think this is a sign for me to write some patterns this semester...