In our last blog, The Best Major-City Areas to Live and Work in Life Sciences, we explored the benefits of living in five of the most popular large-city hotbeds of our industry, and found that 56% of DataCeutics’ programmers, data managers, and statisticians live in, and work out of these areas. The opportunities for exemplary education, premier entertainment, and ease of travel make big-city life attractive to many, but it’s not for everyone.
At DataCeutics, like at so many companies today, the bulk of our employees work remotely from their home offices. We are a Functional Service Provider of SAS Programmers, Data Managers, and Statisticians, and for us, the off-premise work environment model has worked incredibly well, for over two decades. Our programmers, data managers, and statisticians appreciate the flexibility of work hours, savings in travel time and costs, and they also get to live wherever they choose to reside.
The industry is in full agreement that currently, there is a critical gap in the landscape of the Study Data Tabulation Model (SDTM) and Analysis Data Model (ADaM) standards for handling and formatting data to allow for non-compartmental PK parameter calculations. ADNCA will be the new dataset standard that everyone will be using in the future to make PK parameters consistent, and will define how the data should be when it is submitted to the FDA…exciting stuff!
Having worked on a very large number of Statistical Analysis System (SAS) programs, I’ve discovered some better ways to do things, and am sharing some of these discoveries with you. SAS LOG files are scanned to monitor, evaluate, and improve the quality of data processes. Programmers are trained to look for ERRORS and WARNINGS in the data reports when these Quality Control (QC) scannings are performed, but all too often, they stop there.
Many SAS programmers have some SQL knowledge from working with a particular database vendor’s software before they discover that they can use SQL in their SAS programming, by simply enclosing their SQL statements inside of a PROC SQL invocation. They might wonder what the differences are between what they can do with the standard or vendor specific SQL that they already know, vs. what the corresponding capabilities are specific to SAS SQL.