Quentin,

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

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

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.

IanWhitlock@westat.com

-----Original Message----- From: Quentin McMullen Sent: Friday, July 26, 2002 11:33 AM To: SAS-L@LISTSERV.UGA.EDU 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.

Kind Regards, --Quentin