Date: Tue, 27 Oct 2009 18:55:25 -0700
Reply-To: Sierra Information Services <sfbay0001@AOL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Sierra Information Services <sfbay0001@AOL.COM>
Organization: http://groups.google.com
Subject: Re: How can we stop the "do nothing data step"?
Content-Type: text/plain; charset=UTF-8
I am not sure I understand what Dav's issue is here. I don't see
anything in this thread (or elsewhere on SAS-L) asserting, or
assuming, that long-time SAS users are ignorant and/or lazy. Many
long-time SAS users I know are like Dav in that they're looking to
expand their SAS skill set via formal training classes, participation
at user group meetings, etc.
Then there is the distinct minority of long-time SAS users who refuse
to pick up a manual, explore new features of SAS, keep an open mind
about new ways to do things, or to take advantage of resources to
expand their SAS skills. The person who I described in my earlier
thread on this post absolutely refused to update her SAS skill set for
over 25 years. I never said she was ignorant, or lazy. She knew what
she knew and applied what she knew to her assigned tasks. My main
issue with her was her hostility and verbal tirades.
What I did say in my previous post is that she apparently refused to
apply any SAS tool that was not documented/available in a 25-year old
version of SAS Software on the grounds that newer documentation
manuals "had too many words in them."
What I did not mention in my previous post is that while giving the
training class to her co-workers I had a chance to see some of the
programs she had written, and they were among the most inefficient and
poorly written examples of "expert" SAS programming I had ever seen.
She clearly did not understand the concept, benefit or value of a
permanent SAS data set, or how to use tools like PROC MEANS to
calculate descriptive statistics / summary data sets or to use either
PROC REPORT or PROC TABULATE to generate reports. Instead, she has
hard-coded a series of tedious DATA _Null_ steps to calculate
descriptive statistics and then generate 'custom' reports. Most of
what she generated on the mainframe was then manually re-keyed in to
Excel spreadsheets which were then turned in to PDF files for
distribution.
In her mind, I guess she was a "hard worker" because of the amount of
time it took her to write programs generating ad hoc reports and
analyses. Had she taken a less obtuse approach to her SAS knowledge
base over the past 25 years, she would have probably found easier ways
to accomplish her assignments. And, her programs would have consumed
far fewer computing resources at her work place.
Also, I have to respectfully disagree with the idea that "newer users"
of SAS are "close enough to the latest version that they can't have
any outmoded habits--yet." Many "newer users" of SAS work from
programs they have "inherited" from "experienced users" and these
"newer users" often don't understand what these legacy programs do, or
how they might be improved. More than once I've gone someplace to do
a training class where the attendees have said "well, we just use the
code that Fred left us before he retired. We don't know how it works,
it just gives us what we want, at least some of the time." When that
situation occurs, Fred's bad habits are propagated to the next
generation of SAS users.
Earlier this year, for example, I did a series of training classes for
a quasi-independent public health/disease tracking organization here
in California where the same pieces of inefficient, undocumented, and
poorly written code were being passed around among the researchers,
none of whom had had any formal classroom training on SAS
programming.
One of these programs analyzed a foodborne illness survey that had
maybe 50 questions on it. Each of these questions needed some
recoding done, so the "experienced" programmer wrote 50 separate data
steps, one for each recode. Then they wrote 50 separate PROC FORMAT
steps, each creating an identical (except for the format name) series
of format lables for the values of these recoded variables. Then, 50
more data steps were written to associate the 50 formats to the 50
variables. So, we had 100 data steps and 50 PROC FORMAT steps in what
had become a monster program that was almost impossible to modify
every time a new foodborne illness survey was developed.
It was with great glee that I reduced this mess down to one data step
with one Array Statement and one PROC Format step. The people in the
class were astonished at how quickly and easily they were now able to
take this code example and apply it to future foodborne illness
surveys.
But, let's take a step back here. I did this in January of 2009 using
SAS 9.2 software. BUT, everything I did to clean up the code was
available at least in Version 6 of SAS, which was released in 1990 or
1991, if memory serves. So, to me, the issue is not with the release
of SAS one uses, but with the attitude you take towards applying SAS
tools to their job. Fortunately, most long-time SAS users are like
Dav and others on SAS-L and not like the person I described who
refused to look at anything other than her V79 manual for the past 25
years.
Final anecdote for this post: Every once in a while someone asks me
what they need to do to be an effective SAS user. My response is
usually that they should understand core SAS processes like Data and
Procedure steps, and to learn the roles of things like assignment
statements, functions, and formats. They should also learn how to use
core BASE SAS procedures such as FREQ, PRINT, MEANS, REPORT, TABULATE,
SORT and CONTENTS, as well as any analytical PROCs relevant to their
area of expertise. But, I also say "you need to be willing to look it
up int he documentation." Without that skill/orientation, you're
doomed to spend far more time doing things the hard and inefficient
way!
Thanks for taking my thoughts in to consideration....
Andrew Karp
Sierra Information Services
http://www.sierrainformation.com
On Oct 26, 7:15�am, David.A.Vandenbrou...@HUD.GOV ("Vandenbroucke,
David A") wrote:
> >Date: � �Sun, 25 Oct 2009 16:54:29 -0700
> >From: � �Sierra Information Services <sfbay0...@AOL.COM>
> >Subject: Re: How can we stop the "do nothing data step"?
> >Yes, I could not agree more. �In 2005 I was hired through a training
> >broker to give an intro to SAS programming class to a group of
> >mainframe programmers in the IT function at a large county government
> >near Washington, DC.
>
> [amusing anecdote omitted.]
>
> >Greatly relieved, I came back a few weeks later to give the class. �To
> >this day, I wonder how many other "SAS experts" there are coming to
> >work every day whose knowledge of the product has not advanced much
> >since the V79 (or even V82) days.
> >Thanks for letting me rant for a bit....
> >Andrew Karp
> >Sierra Information Services
> >http://www.sierrainformation.com
>
> I note that Mr. Karp works for a training company and thus might be more sensitive to SAS users who are not keeping their skills up to date. �I have no doubt that there are such people and that his anecdote is an accurate description of the incident. �On the other hand, I do take issue with the general presumption in this thread that long-time SAS users are generally ignorant and lazy. �I started writing SAS programs on punch cards in the late 1970s. �My most recent SAS training course was last May, and I am currently working on my training requests for the next fiscal year. �I rather think that my long-time colleagues in my organization are more like me than the woman Mr. Karp described.
>
> It's a truism that only older users can be set in their ways. �The "ways" of newer workers are close enough to the latest version that they can't have any outmoded habits--yet. �(It remains to be seen whether the newly trained will continue to update their current status or not.) � �Thus, any anecdotes about failure to keep current are necessarily going to involve experienced users. But, as we all know, anecdotes are not evidence. �I grow tired of the easy assumption that experience programmers are mostly obsolete and inert. �That, as I say, has not been my experience--another anecdote, to be sure, but no less valid that the entertaining stories already posted.
>
> Dav Vandenbroucke
> Senior Economist
> U.S. Dept. HUD
> david.a.vandenbrou...@hud.gov
> 202-402-5890
>
> I disclaim any disclaimers.
| 
