Once in a while at interviews or on an assignment I will be asked quite
searchingly by a hopeful person, how that person can become a good sas
programmer. I usually give an answer but the answer will vary from person
to person. I never have time to explain my reasoning in those circumstances
so I thought I would put my thoughts down on this page. This page is not
about learning syntax, what to learn or following company programming standards
or anything like that. That is just part of the job. Bear in mind that
just as I am asked my personal opinion, what follows is my personal opinion
and nothing more.
"Born to be" programmers
There is no doubt in my mind that some people are "born to be" programmers.
You can become a good programmer without being such a person -- but if
you are it helps! If you were "born to be" a programmer then you would
have been programming on and off since you were a teenager. That is the
simple test. A "born to be" programmer will pick up programming languages
by reading manuals and trying things out. They have the patience to do
this, a technical orientation and a focussed mind. SAS is an easy language
in comparison to what is out there so a "born to be" programmer will have
no trouble becoming good at sas.
A "good programmer"
If you are not a "born to be" programmer then do not worry, but a little
of the need for this lingers on. Note that the word "sas" is missing from
the title of this section which is "A good programmer". This is for a reason.
In my opinion, you can not be a "good programmer" if you are a one-language
programmer. If sas is the only language you know then, in my opinion, you
can never be good at it. A programming language is a tool to do a certain
job. Different languages do different things and can achieve different
things. Scripting languages, for example, can achieve automation and great
efficiencies on the platform you are working on and you may never do anything
vaguely mathematical in years of using these scripting languages. A "good
programmer" understands that different languages are for different purposes
and will not limit their thinking to the way they code using sas. It is
a mistake to become set in a mold as it will stop you from seeing the greater
scope and purpose of the work you do. It is better to think freely and
look around for the language to help you achieve your task. There is a
lingering piece of "born to be" programmer at work here though it is very
slight.
Advice to non-experienced programmers
If I recognise that somebody is already a good programmer and wants to
pick up sas then my task is easy. I would recommend them to look at a good
sas programmer's style and use that to guide them. After a year or so,
with a good style as their foundation, then that person will be able to
branch out with their own style. For a person who is not already a programmer
then it is more difficult. What makes it difficult is the assumptions the
aspiring programmer is making. Not being a programmer at all, they have
no grasp on what it takes to become a programmer. They will assume it is
something that can be learnt from a book. It can't and there is no such
book. There is no hidden knowledge. The aspiring programmer will have to
become one by trying out the language on examples and dummy data. They
will have to discover "right" and "wrong" ways to do things and prepare
to have their views changed as they gain experience. It is essential to
try things out otherwise you will not make progress. If you do not get
the opportunity to experiment at work then you can always buy a copy of
SAS Learning Edition and experiment at home. You might not like the price
of the Learning Edition but you can think of it as an investment. This
will be an uphill struggle for many aspiring programmers but if you stick
to the task then you can start becoming good after a year or so. I changed
over from the field of Capacity Planning, using SAS, to the field of clinical
reporting and it was an uphill struggle for me for the first year, even
with more than ten years SAS experience. It will be hard for you as it
was hard for me. Patience is required. Don't push yourself too hard. Do
not try to "better" another programmer or reach their standard as a goal.
You will find your own level. Being technically brilliant is not everything.
Being able to function as part of a team is more important. This is more
likely to get you promoted to senior programmer through to Head of Programming.
Those who are very technical tread a lonely road. My advice to non-experienced
programmers who may not feel comfortable with the technical issues of SAS
is to concentrate on the team aspects of their work.
How much SAS should you know?
The SAS language covers a vast scope. There are areas of SAS I have not
even touched upon. There is the "object orientated" aspect of it that I
know nothing about. I have not touched many of the stats procedures and
those that I have, my knowledge of them is superficial. I used to write
SAS/AF applications but the facilities have changed greatly since I last
used it. There is sas IML which I only used for a day. There is ODS which
I have used a lot but still have only scratched the surface. There is SAS/OR
that I have never used but it strikes me as important. Neural networking
with sas I am aware of but have never used. Modelling for business I have
not touched and know nothing about and there is so much more I have probably
not even heard of. I was once asked in an interview how much of the entirety
of the SAS language I could say I knew. I answered "Between 15 and 20%".
And this is with over 20 years of experience doing some very technical
things over a broad range of applications. This was not a confession of
ignorance -- it was more of a boast. I would say that knowing 10% of the
SAS language is a good level to reach so long as you realise that there
is so much more and you are prepared to look beyond your limited experience
as to what the SAS language can offer you.
Keep it simple
On a final note, my last piece of advice is to "keep it simple". I have
seen many programmers, both new and experienced programmers, code in a
complex way. Maybe they think it proves to others that they are good programmers
if they code that way. This is a bad idea. It is better to code in a way
that does not draw upon peoples mental energy who may have to maintain
your code at a later date. Included in this is commenting your code well,
maybe also splitting long code into clearly-marked sections to make it
easy to understand. That way the maintainers can better understand it and
can make amendments, if required, that in turn can be maintained in the
future. On a similar note, macros should not be overused such that you
are turning things into macros where there is no good reason. If your use
of macros is not simpifying your code and instead, making it more difficult
to understand, then you are using macros incorrectly. This web site has
many tips on writing macros that can help you.