Date: Fri, 12 Jan 2007 15:59:17 -1000
Reply-To: Bob Schacht <schacht@hawaii.edu>
Sender: "SPSSX(r) Discussion" <SPSSX-L@LISTSERV.UGA.EDU>
From: Bob Schacht <schacht@hawaii.edu>
Subject: Re: Support for my readability & continuous improvement soapboxes
In-Reply-To: <7.0.1.0.2.20070112152402.0369c8d0@mindspring.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
At 02:37 PM 1/12/2007, Richard Ristow wrote:
>At 08:28 AM 1/12/2007, Art Kendall wrote:
>
>>While going through some old notes I came across these quotes.
>>
>>Programming can be fun, so can cryptography; however they should not
>>be combined.
>>
>> Kreitzberg and Shneiderman
>
>Two more, for which unfortunately I don't have attributions:
>
>"There does not now exist, and never will, a language in which it is
>the least bit difficult to write bad programs." . . .
May I join the fun? Here's some loose change:
While an undergraduate at the University of Wisconsin decades ago, I
majored in both Math and Anthropology-- two separate but simultaneous
majors. I was also a computer programmer. The thinking skills that were
required were very different. SPSS is, of course, a natural bridge between
statistics and computer science, on one hand, and a social science such as
Anthropology on the other hand.
What I found most helpful in Math and Statistics of any sort-- as well as
in computer programming-- is logical rigor of a kind seldom encountered in
the Social Sciences (there are competing attempts to explain this
difference). Most people on this planet are not prepared for the kind of
logical rigor required in Mathematics and Statistics.
For logical precision, Geometry and algebra in high school are good
preparation for computer programming.
But social science provides interesting examples of studies that can help
people see what all that logical rigor can do.
Of course students should also learn what "testing a hypothesis" means,
including using the terms correctly, and knowing the difference between the
hypothetico-deductive method, and exploratory data analysis. And when to
use them.
It is also very instructive to serve at the "Help desk" of a university's
computer services department. There, you get a chance to see many poorly
constructed research plans and people trying to implement them without the
foggiest notion of what they're doing. As a programmer, we were always
striving to write "User-proof" code, and were always amazed at the ways
people could think of to sabotage their own work (without intending to, of
course).
For a graduate course? a variety of experiences would be helpful, I think.
* Spend some time with some actual programming code, writing a logical
flow chart of how it works.
* Write a simple statistical computer program that will read in data,
perform a few simple calculations, be guided by a few simple user-supplied
options, and print out the results. Get 3 classmates to use your program to
get some results that interest them. And write a report on what you did and
how it worked (or didn't!)
* Volunteer time at a computer help desk, and keep a log of your
experiences.
* Use an online database to test a hypothesis.
* Demonstrate proficiency and understanding of
* testing to see if a distribution is "normal";
* testing a bivariate relationship;
* testing a multivariate relationship.
That's all just loose change, and not to be confused with an actual
graduate course.
Bob in HI
Robert M. Schacht, Ph.D. <schacht@hawaii.edu>
Pacific Basin Rehabilitation Research & Training Center
1268 Young Street, Suite #204
Research Center, University of Hawaii
Honolulu, HI 96814