NOTE: Enterprise Guide Autoexec

I’m part-teaching 10 Tips for Organising Your SAS Enterprise Guide Projects (EG1) in Marlow this week. Thus I was all the more interested to note the latest posting in the SAS Dummy blog wherein Chris Hemedinger lists his top ten EG tips.

The tips ar…

NOTE: Free SAS Book (ODS Graphics)

You don’t have to have an Amazon Kindle device to read Kindle books, which is why the free copies of the Kindle version of SAS 9.3 ODS Graphics caught my eye and led me to acquire a copy for myself (albeit through a convoluted route because I live in t…

NOTE: Free SAS Book (ODS Graphics)

You don’t have to have an Amazon Kindle device to read Kindle books, which is why the free copies of the Kindle version of SAS 9.3 ODS Graphics caught my eye and led me to acquire a copy for myself (albeit through a convoluted route because I live in t…

What *is* a code review?

Our team planned to use a new set of data tables to increase our customer knowledge and overall improve our processes. Due to our workloads, our team lead had a person (Dev X) from another team write some code to access the tables and create some usable datasets for our process. After the code was written, Dev X was asked to arrange a meeting to review the programs. In short, it did not go well. It was not anything Dev X did, it was what did not happen that contributed to the issue. So what went wrong and what can you learn? Mistake #1: Presuming data knowledge What Happened Dev X asked first what our SAS skill level was – the team lead answered “Advanced – macro writers“. Dev X then walked us through the code explaining how SQL joins worked, purpose of LET statements, and how various SAS functions worked, etc.  Frankly – it was insulting and a time waster. What Should Have Happened It was good to ask our skill level. If Dev X had been misled in the past, a few questions to qualify “Advanced” would have been good. “Do you use SQL to join, are you […]