Additional profile information on Alfred Thompson at Google+
In some ways I think this is one of those proverbs that was more important back in the days when batch jobs were the way things worked. On the other hand there is an important, if perhaps more general, bit of advice here. That advice is to spend the time up front to get the right results before getting too hung up on how those reports are handled/displayed.
A lot of developers, and students are horrible at this, like to spend a lot of time on appearances before they get the "invisible" parts of the program working. More than once I have seen a student turn in a beautiful program with a great looking user interface that fails to execute the most basic of functions. I've heard a lot of teachers complain that this sort of thing is made worse by tools that make creating fancy graphical user interfaces easy. There is no doubt that playing with a GUI can be a distraction. People need to remember that incorrect or insufficient information is of little use no matter how pretty it looks.
IN most cases getting the output to look great, whether that means the columns line up or the screen is well laid out and well organized, in a fairly trivial task. It may be tedious at times and there may very well be a good deal of testing to make sure all of the edge cases display well. But really getting the output right can usually be safely left until later in the development cycle. IN professional development it might even be better to make that task a separate on and hand it off to graphic designers rather than programmers. The promise of XAML and the Expression Suite of tools among others (someone else must be doing similar things I assume) make that easier. Form and function have never been easier to separate.
A programmers main job is to get the algorithm coded correctly and tested well. Once the program is correct someone can spend the time needed to make it look cool to the user.
This is the twenty-second of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
I've never been very good at taking notes and here are NECC hasn't been much of an exception. While I have blogged about a number of sessions for the most part I have just listened intently but not blogged or taken notes. I have to say that I regret this somewhat.
So I am trying again during this session on teaching Object Oriented programming using Visual Basic 2005. Beth Brown of Lawrenceville Press is presenting. Beth is the author of the highly regarded VB textbooks from Lawrenceville Press. She is starting off by talking about how VB is now a real OOP language as well as some of the features new since VB 6.0.
She's been talking about the Sound objects and the My Namespace. When we talked about these features before he talk Beth said that before these additions there were a number of things that used to be hard to do and that while they are fun and easy now, previously they had involved too much overhead to teach.
Beth is talking about incorporating animation, sounds and color to make programs more fun and interesting. She says that students will work hard to learn new concepts in order to make their programs more visually interesting. Beth is promoting one of my favorite ideas - providing partially completed code and having students complete it. I have long found that this allows me to focus the bulk of student's efforts on specific topics.
One of the handouts Beth provided was a correlation between the APCS A curriculum outline and the chapters in her book. For the most part the things not covered are highly Java specific libraries and it looks to me like one could cover all of the concepts in the APCS A curriculum pretty easily using Visual Basic. And in my somewhat biased opinion students would have more fun learning it all in VB.
At this morning's NECC keynote discussion Elizabeth Streb noted that students who come to her workshops have time to play before the lessons start but that the line between when play ends and learning begins is very often blurred. Mitchell Resnick at the MIT Media Lab's Lifelong Kindergarten talks about the same thing - for example what kindergarten children learn playing with blocks.
And yet it seems as though all too often we try to suck all the fun and play out of education. We act as if learning only happens when we are serious and that it is almost better if "learning" is painful and boring. And then we wonder why kids just can't wait to get out of school. Am I one of the few who sees a problem here?
I watched a demo of the various FIRST Robotics competitions yesterday here at NECC. The joy of learning that students of all ages shown there was electric. Kids will learn what they need in order to play in games, in sports or to do entertaining things. We see them going through hoops to learn how to create videos and podcasts, web pages and blogs, and toys and video games of enormous complexity. Why aren't we taking more advantage of the motivations that drive students.
At this morning's keynote Mary Cullinane in her final remarks highlighted the need, the necessity, for teachers to understand the motivations of students in order to teach them best. Fun is a huge motivator. It's not the only one of course but it is an important one.
I see huge potential in educational games. TO some extent teachers are and have been using games for years of course. But I think that computers and the simulation technologies that are being developed for business and for commercial games have an as yet under accepted potential for helping to teach students. Rather than "commercial games" I started to write "non-educational games" but I wonder if perhaps all games are educational in some way. But are they all teaching lessons we want taught? How do we best harness this technology for good?