Date:         Thu, 7 Sep 2000 14:10:54 -0400
Reply-To:     "Kerrison, James" <James.Kerrison@FMR.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Kerrison, James" <James.Kerrison@FMR.COM>
Subject:      Re: Essential-but-overlooked Technical skills in SAS?
Content-Type: text/plain; charset="iso-8859-1"

I am going to add to this by saying that I think the first thing a
programmer needs to know how is how a data step is compiled and executed. If
they know this then I believe that they are a long way down the road to
success. I taught myself to code, and learned most of what I know about SAS
through a.) trial and error, b.) Manuals, and c.) SAS-L. It took me ages to
figure out what the PDV did even though it is a basic requirement to
understanding the datastep. My code is often crude, and inefficient, as a
result. If I understood more about the "mechanical" process that SAS goes
through I would be a better programmer, and would have saved myself some
embarrassment along the way!!

For me; moving up to arrays, do loops, if then statements, retain, and
applying functions is the next step. I would also include being familiar
with SAS syntax in this phase. Knowing that SAS will do something you expect
is a big thrill, a big relief, and does wonders for your confidence!

Finally - maybe because of where I am at - I think that macros represent the
pinnacle of SAS programming skills. I think that is so because you are now -
generally - working in the abstract so you need to know exactly what is
going on to achieve a good result. I think it was Paul Dorfman who said in a
posting recently that a program should process data, not contain it. Think
about it!

I have never figured out what constitutes the difference between a novice,
intermediate, and advanced programmer.

I say this in the overall context of working with certain types of data, and
doing certain types of work. In other words if you start out in the
pharmaceutical industry working with gazillion record files, and complex
data manipulation then you become familiar with that kind of programming.
Move from there to a different type of shop, and your skill set might need
some revisions!

Regards,

Foster Kerrison.


-----Original Message-----
From: Greg Woolridge [mailto:greg.woolridge@TAP.COM]
Sent: Thursday, September 07, 2000 1:04 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Essential-but-overlooked Technical skills in SAS?


OK Doug, I'll put in my 2 cents.

When I am looking for a new programmer I expect him/her to at least be
familair with the following:

data _null_
substr function
scan function
index function
what a macro is and how to call it (how to write one is a plus)
%let
by statement
where statement
if, then, else
do loops
arrays
proc freq
in= option for data sets

Since we do a lot of report writing in my shop, I find myself looking for
knowledge of proc report a lot more these days.

Hope this helps to get the discussion headed in the direction you want.

Greg M. Woolridge
Manager, Study Programming
TAP Pharmaceutical Products Inc.
e-mail: greg.woolridge@tap.com
phone:  847-582-2332
fax:  847-582-2403



                    Doug Zirbel
                    <doug_zirbel@HO        To:     SAS-L@LISTSERV.UGA.EDU
                    TMAIL.COM>             cc:
                    Sent by:               Subject:
Essential-but-overlooked Technical skills in SAS?
                    "SAS(r)
                    Discussion"
                    <SAS-L@LISTSERV
                    .UGA.EDU>


                    09/07/00 11:10
                    AM
                    Please respond
                    to Doug Zirbel





I posted this query, with slightly different wording, last Friday, and was
surprised by some of the results.

Namely, several of you stressed sound theoretical understanding of the
software development process (syst dev life cycle, Carnegie-Mellon Software
Engineering Institute Capability Maturity Model, documentation,
requirements-gathering) etc.

In other words, there are some higher-level skills which should be part of
"the basics."  Point well taken.

Now, what about those strictly technical SAS skills?  Yes, everyone should
know how to write a data step, proc print etc etc, but...

don't you run into SAS programmers from time to time, who are simply not
even aware of some function or proc that you use all the time?
... or, (null hypothesis) do all experienced SAS programmers already know
90% of the "most productive SAS technical skill set"?