How to become a good SAS programmer

Last updated: 14 Jun 2015

Introduction

Once in a while, at interviews or on an assignment, I will be asked by somebody hoping to do SAS programming work, 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 had the time to explain my reasoning in those circumstances so I thought I would put down my thoughts on this page. This page is not about learning syntax, what to learn or following company programming standards as that is just part of the job. It is about the extra attributes that it is good to have or to develop to be a good SAS programmer.

Bear in mind that just as I am asked my personal opinion, what follows on this page is my personal opinion.

"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 for these tasks. 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 use the usual language they work in. 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 goal. There is a lingering piece of "born to be" programmer at work here though it is slight.

Experienced programmer converting to SAS

The conversion of a programmer from using languages that do not handle a lot of data to using SAS which does, is a difficult one. A lot of relearning has to be done. There are usually two phases to a SAS program - pre summarization and post summarization. The experienced programmer has to learn a dual approach for these two phases. For pre summarization they have to learn to use as few data fields as possible with as little processing as possible to get the large volume of data to the summarization step in a minimum elapsed time. After the data is summarized then the number of observations is a lot less and so this is the stage to manipulate the data into the form you want. The efficient handling of large volumes of data is paramount in SAS programming. This is covered on the "SAS Speed Tips" page.

For this category of experienced programmers from other languages, it is possible to be one of the best programmers in the world at the same time as being one of the worst SAS programmers in the world if this "dual approach" is not recognized and worked on.

Advice to non-experienced programmers

If I recognize 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. 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 as 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 path and are often not appreciated. 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 there is much more. 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 it. 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 percent" - and this is me with over 25 years of SAS 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 realize 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 simplifying 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.

How new programmers are giving less than before

Since I started out in programming as an industry trained programmer in 1984, the job has lost a great deal of its reputation and prestige. A major reason for this is that computers are much cheaper than they and more computer languages exists and it is easier to write them - so this is understandable. But in 1984, programmers starting out in the industry were giving value for money in what they were doing and I don't feel that programmers are giving value for money in the present day. A programmer who is not giving the same value for money now is not entitled to the respect nor the salary equivalent in modern day terms as programmer were getting then. It is no wonder that so much work is being outsourced. Programmers today are not as good as programmers used to be in 1984 when I first started out in computing. The situation is worsening to the extent that some companies might need to bring some of their old programmers out of retirement to give them part time working to make up for the skills gap in programming that now currently exists.

Here are some examples of how programmers were giving value for money then but not now:


 
 


 
 

Go back to the home page.

E-mail the macro and web site author.