'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. -----