SAS has been the undisputed market leader in commercial analytics space. The software offers huge array of statistical functions, has good GUI (Enterprise Guide & Miner) for people to learn quickly and provides awesome technical support. However, it ends up being the most expensive option and is not always enriched with latest statistical functions.
1. Availability / Cost:
SAS is a commercial software. It is expensive and still beyond reach for most of the professionals (in individual capacity). However, it holds the highest market share in Private Organizations. So, until and unless you are in an Organization which has invested in SAS, it might be difficult to access one.
2. Ease of learning:
SAS is easy to learn and provides easy option (PROC SQL) for people who already know SQL. Even otherwise, it has a good stable GUI interface in its repository. In terms of resources, there are tutorials available on websites of various university and SAS has a comprehensive documentation. There are certifications from SAS training institutes, but they again come at a cost.
3. Graphical capabilities:
SAS has decent functional graphical capabilities. However, it is just functional. Any customization on plots are difficult and requires you to understand intricacies of SAS Graph package.
“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. T
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.
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.
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.
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:
- New programmers learned from their team members. It was accepted that a new programmer would be worth nothing for the first six months, would only be able to create small things of worth after six months and only under the supervision of the more experienced team members. And so new programmers made the effort to learn and were appreciative of the help and advice they got from their team members. The same applies today. New programmers need to realize that their contributions initially are worthless and to make the effort to learn from more experienced people. New programmers knew that and made the effort to pick up experience. Through this effort to learn from others they grew into better programmers and thus were, after two years or so, able to give value for money. This is not happening any more. New programmers are looking for quick results and think that that is enough. But it is a bad approach because they stop learning too early.
- Experienced programmers made the effort to help their junior colleagues. They should still be active in doing this if they are to give the industry value for money. They should help other programmers and not just think of themselves and what they know and what they think they are worth. To create a more useful programming field for the benefit of all, they should give freely of their knowledge (and experience if possible). Today, it seems that the more experienced programmers want to keep their knowledge to themselves, perhaps for competition reasons, but it makes the whole programming field weaker if they do that, which eventually will devalue their own work.
- Make up for the job getting easier. When I first started out in programming, the job was incredibly difficult. You were expected to be able to write fully correct and working code if not on your first attempt then your second attempt. You might not even get any diagnostics when you compiled your program so you just had to get it right without any help from the compiler. If your program went wrong then a “system dump” would be printed of all the hex codes in computer memory and you would have to work out what had gone wrong with your code from the memory dump. It was called “dump cracking” in those days. That was incredibly difficult and such difficult jobs working on expensive computers were worth a good wage. If things have gotten easier since then, then to justify the same level of wages and enjoy the same respect, we need to do more. Maybe to think of how problems might arise in the future and avoid them. Maybe to see a bigger picture and how things need to fit together and plan and write computer systems accordingly. To design and write entire computer applications rather than just individual programs. But most programmers today do the minimum and expect the same appreciation. Often, they do not bother to keep up to date with new features and enhancements in the computer language they use.
For More Information Please Follow the below Link:
Course Link: http://www.xoomtrainings.com/course/sas-clinical