Your raise a fascinating question on the role of the organization in
fostering the individual learning SAS. I agree that it can pay big
dividends for the companies that learn how to answer that question well.
However, in many cases it comes down to the individual and what he is
willing to put up with.
If one of the requirements were working for an organization fostering the
learning of SAS then there would be very few good SAS programmers. I think
most of them learned in spite of all organizational road blocks. Phil Rack
[PhilRack@MINEQUEST.COM] wrote one of the few counterexamples.
As you know, after Randy Herbison's Westat talk on AF this afternoon, I
asked how and why he learned AF. To me the essential ingredient was
perceiving a need to supply finished systems for people who knew little SAS.
He did not indicate whether it was an organizational decision, but from the
way he answered I bet it was largely a personal decision filled with
personal hardships to do whatever it took to fill the need that he
When I think of my own background, it was pretty much the same thing. I
started working in a FORTRAN shop where it was common to produce 50 line
programs to answer statistical requests. I soon recognized that most of the
requests fit a set of standard types. I adopted the policy that the first
time I would write the 50 line program, the second time I would think about
the relationship with the earlier request and the third time I would not
stop until I had a general program that could handle all requests of that
type. The management philosophy was the request has to be done on time.
For me that meant working from 7:30 AM to midnight. It was the wisdom of
the company to let me work after hours. The company supplied the computer
and I supplied the hours. I learned.
I jumped to SAS for the same reason, it handled my problems better than my
FORTRAN system. And again it took long hours to pay off. In part that is
why I objected to Michael Raithel's thesis that all it takes is curiosity.
I think it takes tackling problems to learn SAS, usually at an individual's
Of course, if any companies do learn to foster the environmental issues you
raise they will clobber the companies that don't, whenever SAS is important
part of their produce.
From: Quentin McMullen
Sent: Friday, July 26, 2002 11:33 AM
Subject: Re: Best Ways To Learn SAS?
Ian Whitlock wrote suggested the following requirements for learning SAS:
> First what are the requirements?
> Modest intelligence
> Hungry enough
> Available information
> Means to execute SAS
I agree with Ian (of course), but as a bleeding-heart liberal (try sending
that one through babelfish : ), I think it's also important to consider
characteristics of the *environment* one is working in, in addition to
traits of the individual. Beyond simply access to SAS and available
information, what should the environment give you?
As someone comitted to learning SAS, I need to evaluate my environment and
decide if it enables/encourages me to learn SAS. For different people, this
may mean different things. For some people it could be "leave me alone in
my office where I'm the only one in the company doing SAS, and I'll read
manuals, papers, SAS-L and become a wizard". For other personality-types,
it could mean "put me as part of a group of programmers, where there will be
in-house trainings, and folks prodding me to go to conferences, and everyone
is talking SAS over lunch breaks". So it's up to each person to decide what
sort of environment would work best for him/her and then look for that
environment (oops, I'm getting dangerously close to individual
responsibility, better get back to Cambridge soon).
On another point, I think it is essential for both the organization and the
individual to maintain a long-term perspective on SAS skills/production
capabilities. If the only valued objectives are short-term production
goals, it is easy to fall into the trap of stopping to learn SAS. Thus, the
beginner in this trap thinks "well, the requested delivery is means and
frequencies, I already know how to produce them with PROC MEANS and PROC
FREQ, no time to learn TABULATE or REPORT", or "well, I can just
cut-and-paste this data step 10 times and edit each one, no time to learn
macro". The growing programmer within a supportive organization needs to
balance immediate production requirements against long-term development.