Sunday, January 25, 2015

Are You Doing Things SAS Backwards?

SAS Programming Professionals,

Are you doing things SAS backwards?

Yea; we have all been there.  A manager, or a user, or a client, asks you to perform an analysis or create a data set and gives you a sketchy description of what they want. Maybe they say "It's like that report you did last November", or they send a few descriptive lines in an email, or they verbally describe it in a meeting, or they sketch out some ideas on a notepad.  So, you dutifully write a program that processes what you think is the relevant data and creates the result set you believe they want. You QC the results, present it to the requester and... you are told that it is not right.  So, you modify your program according to their feedback and create the next result set.  And, it is still not right.  You find yourself repeating the process again and again until your manager or user or client is finally satisfied.

What is wrong with this process is that you are starting to write a SAS program when you do not have solid specifications.  Not understanding exactly what the requester wants invariably leads to wasted programming time.  So, you need to get your user to be specific about what, exactly, s/he wants before you start programming.  At a minimum, the requester should define:

Input
  • The data sources you are to extract the data from
  • The selection criteria you are to use to subset the data
  • The variables they want in the final data set or report
Process
  • What types of analysis they want performed on the data
  • The formulas for any new variables that are to be created
  • Any transformations that are to be made to existing variables
  • What to do with missing values for important variables
  • Whether any variables should be suppressed from the final result set
Output
  • For data sets, the type of data set and the variable order
  • For reports, the layout of the report, including variable order, headings, titles, footnotes, and summary columns
  • For graphs, the type of graph, variables to be graphed, titles, legends, footnotes, and reference lines
  • The type of additional documentation needed, such as a PROC CONTENTS or frequencies of the delivery data set
The best thing you can do is to have your user send you the specifications in writing.  That performs two functions:  It makes the person stop and really think out what s/he wants, and it gives you a solid starting point.  From there, you can ask questions to fill in any of the details that were not covered in the original, written request.  After a few iterations, you should have a solid spec to work from.

If you only receive verbal directions or sketchy notes via email and are not likely to get anything more solid, you may have to write the specs yourself.  In that case, you would write down the details of the Input, Process, and Output steps that you believe your client wants and send them to the client.  Let your client review the specs and verify that they are what s/he wants, or suggest changes to your proposal that better define what is needed.  Once the email exchange culminates in fully ratified specs, you are good-to-go with starting the SAS programming.

Almost invariably, any programming effort--no matter how well spec-ed out--will require an iteration or two to satisfy a user's requirements.  However, you can drastically reduce the time you spend programming by nailing-down your user's needs as much as possible before you begin to write your SAS program.  Few things in life are more satisfying than creating a tight, elegant, efficient SAS program that conforms to specifications and that produces the requested result set.

Remember; without specifications to refer to, you cannot judge whether or not the program you wrote and the result sets you created conform to the requirements.  And, as Lewis Carol wrote:  "If you do not know where you are going, any road will lead you there."

Best of Luck in all of your SAS endeavors!

----MMMMIIIIKKKKEEEE
(aka Michael A. Raithel)






Monday, January 12, 2015

Did You Know That 15 Minutes Could Save You...? Yea, Everybody Knows That!

SAS Programming Professionals,


You would have to be a caveman to not be familiar with the "Did you know that 15 minutes could save you 15% or more on car insurance?" advertisement.  Multiple versions of the commercial are on television, on the radio, on the Internet, and likely on every other medium that has ever hosted that cute little gecko with the cheery British accent.


Well, the same sort of thing is true about SAS programming.  I would state it this way:

Did you know that studying SAS for 15 minutes a day could save you hours of programming time?
It is true.  Knowledge is power, and the more SAS knowledge you have the more powerful is your SAS programming prowess.

Some programmers are content to simply let their work tasks take them wherever they may lead, and to learn additional SAS programming hacks from solving the various software development problems that arise.  They hit a problem that cannot be solved with the SAS that they know, look up additional PROCS or functions, or options, or call routines, or SQL statements, etc. and use the new material to resolve the question at hand.  Fair enough!  On the job training is good, and it may make sense to let real-world problems dictate some component of your SAS acumen.
But, relying solely on a stimulus-response type of SAS learning is a bit short sighted.  A better way to increase your SAS knowledge is to be aggressive and actively study SAS.  That way, when you bump into a programming problem you have not previously experienced, you can reach into your in-memory SAS toolkit and pull out one of the SAS hacks that you have read about, but not yet had an opportunity to try.  You will already be familiar with the concept, so you will not need to spend much time coming up-to-speed on it.  Instead, you can customize the PROC, or ODS template, or hash, or... whatever to resolve the issue and go from there.
There are two things you need to implement this proactive approach to increasing your SAS knowledge:  fifteen minutes each day, and good material to study.
Fifteen minutes is only 1% of the 1,440 minutes available to you in a day.  So, it should be easy enough to find fifteen minutes to study SAS each day, right?  Well, that can be problematic for all of us.  We have so many work and personal commitments to attend to, that every moment of every day seems to already be scheduled with other things to do.  So, we need to get creative.  Perhaps you can take fifteen minutes on the subway or bus commute to work to read SAS material.  What about taking fifteen minutes the moment you get into your office before you begin reading emails?  How about using fifteen minutes of your lunchtime to read new SAS hacks?  Or, maybe fifteen minutes at bedtime.  Whatever time slot you decide upon, try to make it your own, inviolable, uninterruptable SAS study period each day of the week.  If becoming a stronger SAS programmer is important to you, you will find that elusive 1% of a day.
Regarding good material to study; there is a plethora of great SAS programming publications out there.  But, for "... studying SAS for 15 minutes a day ...", I recommend one of the SAS tips books.  Here are my recommendations:
Of course the first recommendation is my favorite because I am the author.  However, you absolutely cannot go wrong with any or all of the publications in my list.
So, did you know that studying SAS for 15 minutes a day could save you hours of programming time?
Well yea; everybody who read this blog knows that!
Best of luck in all your SAS endeavors!
----MMMMIIIIKKKKEEEE
(aka Michael A. Raithel)
Author page:  http://www.amazon.com/Michael-A.-Raithel/e/B001K8GG90/ref=ntt_dp_epwbk_0

Thursday, January 1, 2015

Meet the New Year; Same as the Old Year...NOT!

SAS Programming Professionals,

Happy New Year to you, your families, and your colleagues!

This is the time of year when people make all types of New Year's resolutions.  According to the USA.Gov web site, the most popular resolutions are:
  1. Lose Weight
  2. Volunteer to Help Others
  3. Quit Smoking
  4. Get a Better Education
  5. Get a Better Job
  6. Save Money
  7. Get Fit
  8. Eat Healthy Food
  9. Manage Stress
  10. Manage Debt
  11. Take a Trip
  12. Reduce, Reuse, and Recycle
  13. Drink Less Alcohol
And, these resolutions all make sense because they promote personal growth.  It is a new year, so why not start making the changes that you want to carry forward throughout the year?

Along with personal changes, perhaps it is also time to consider what changes you could make to improve your SAS programming skills.  There is no "most popular list of SAS resolutions" for us to reference, so I will suggest some:

  1. Lose unnecessary variables and observations when inputting data sets
  2. Volunteer to help junior SAS programmers
  3. Quit writing programs without comments in them
  4. Get a better understanding of the intricacies of PROC SQL
  5. Get more sophisticated in your SAS Macro programming
  6. Save time by re-purposing your old programs
  7. Purchase some interesting SAS Press books... and read them
  8. Join a local SAS users group and attend meetings
  9. Get better at using the Output Delivery System
  10. Take a SAS class
  11. Write a technical paper for SAS Global Forum
  12. Reduce processing time by writing more efficient programs
  13. Subscribe to the SAS-L listserv
Hardly a comprehensive list, but definitely a good start, no?  And, I would bet that one or more of these resolutions resonate with you; that they are things you have been wanting to do, but have not quite found the time to work on in 2014.  Well, there are 364 more days of 2015 just waiting for you to dig into your own SAS resolutions.

Of course, you could simply sit back and do the same old, same old.  But, how could you continue to achieve personal growth as a SAS programming professional if you did that?

Meet the new year; same as the old year--Oh, we really think not!

Best of luck in all your SAS endeavors!

----MMMMIIIIKKKKEEEE
(aka Michael A. Raithel)