Career path for sas programmer

1
Changing Careers to Become a SAS Programmer in the Biotech /
Pharmaceutical Industry
Sy Truong, Meta‐Xceed, Inc, Milpitas, CA

ABSTRACT
The ebb and flow within the technology sector, ranging from the dot com bubble to outsourcing, has programmers searching
for job security.  Many individuals have considered becoming a SAS programmer within the Biotech and Pharmaceutical
industry due to the longer project life cycle of years rather than months.  The best path to enter this field can be elusive.  There
are challenges especially for those starting out since it requires three years of experience to obtain that first job.  This paper
distills real life stories from SAS programmers within the Biotech and Pharmaceutical industry.  It describes many different
paths and suggests recommendations based upon these experiences.  When starting out on a new career path, sage advice
from seasoned professionals in the field can save a lot of time and energy.  Armed with the knowledge and shared experiences
from the stories told in this paper, you will propel yourself into a more challenging and successful career.
INTRODUCTION
There are many paths that individuals take to arrive at a career as a SAS Programmer.  SAS is a programming language which
requires the rigors of a computer scientist.  However, to become a clinical trials analyst also requires a thorough
understanding and knowledge of the clinical data to be analyzed.  The combination of these distinct skills attracts people from
diverse backgrounds.  It is surprising to find so many different backgrounds of individuals with differing talents and interests
who gravitate towards this career path.  Like many other career paths dealing with technology, things change.  The dynamic
aspects of the job require programmers to become resourceful and to survive.  They therefore must re‐invent themselves
continually.  The core understanding of the analytics behind clinical trials evolves but remains comparatively stable.  Once
you master this and the accompanying programming techniques, you have a good foundation for becoming a successful
Clinical Trials Programmer.   There are many scenarios which you can take.  The following diagram depicts three.  There are
many more and the combinations of steps can lead to a myriad of good paths.

2
This paper evaluates various different paths that individuals took on their road through clinical SAS programming.  There is
no one correct path but rather a diverse set.  This demonstrates the unique combination of skill sets needed to thrive in this
environment.  This position has only recently been established so many of the individuals who entered this field did not set
out to become a clinical SAS programmer.  For many, the journey was unplanned and there were no road maps.  They were
pioneers and navigated their career path following their intuition and relied on luck.  There are many lessons that can be
gained from these pioneers.  The paths which these pioneers paved will provide a clearer vision and set of directions for
future aspiring SAS programmers who plan to venture on the same roads.

ASSOCIATE DIRECTOR OF BIOANALYSIS ‐ DAVID TAPPE
It is not about how good a SAS programmer you are. It is about
being focused on the data and your representation of the data that
leads to success.

Starting Out
When David started out on his first SAS programming position at Syntex in Palo Alto, California in the 80s, this type of work
was not well understood nor well known on the west coast.  The term ʺBioanalystʺ used at Syntex for statistical programmers
was foreign and he did not know what to expect.
David went to UCLA to obtain his bachelors degree in Mathematics.  He then continued his studies at Fresno State in Biology
and did his thesis work in Lymnology, or the study of fresh water ecosystems.  His academic experience did not include
formal computer science nor teach him how to program in SAS, but it did include exposure to research methods and statistics
that he used in his thesis.  In fact, David had little formal programming training.  He was introduced to programming when
he took a FORTRAN course at UCLA.  Back in the days of punch cards, he used FORTRAN for an ecosystem modeling class in
graduate school. Out of personal interest, he learned BASIC programming on his own while working as a Lab Technician at
U.C. Berkeley.  As he developed his career, the technical aspects of programming were merely a means to an end.  That end
was the data itself and how the data demonstrated meaning when analyzed.  The meaning of the data was therefore pivotal
and overrode the mechanics of getting there.  David gained enough proficiency in programming on the job to perform well in
his job without much formal training.
In 1979, David moved to Walnut Creek in the east bay after he had completed his course work in Fresno.  He explored jobs in
the bay area and first worked in the department of Materials Science at U.C. Berkeley helping on research projects aimed at
finding ways to utilize coal dust.  As that job was ending, he found a job announcement at the U.C. Berkeley placement center
for a Bioanlyst at Syntex.  Syntex was an established pharmaceutical company, but due to the lack of experienced statistical
programmers in the bay area at the time, they hired people at entry level.  Although he lacked the job specific experience, he
applied for the job at Syntex because he was intrigued by the blend of statistics, health research and programming mentioned
in the job announcement.  At the time, however, he did not know what a Bioanalyst did or what the job entailed.  The
commute from Walnut Creek to Palo Alto required him to go over the east bay hills, across one of the bay bridges.  This added
to his commute totaling about 60 miles.  The job had to prove to be a good fit for him to keep up with this grueling commute,
even with the help of a carpool.  In the end, it was the research aspect and ability to understand the meaning behind that data
that cemented his decision to stay in this field as a career.
He began to appreciate the goal of producing study reports summarizing the safety and efficacy results of clinical trials.
While he enjoyed programming and developing good SAS programming skills, the output produced by his programs were
more important than the SAS programs.  He began to realize that this was the pivotal aspect of the Bionalystʹs job.  The
Biostatistician, who was the Bioanalystʹs client, wanted to receive quality output tables representing the study data and its
analyses results.  They were not interested in the quality of the SAS program used to create the tables, so long as they
produced accurate results.
The understanding of the disease that he was working on was another fascinating aspect of the job.  He is not clinically trained
as a MD or a RN, but his interest in research and learning about the disease related to a given drug allowed him a unique view
of the data.  This was a window through the data which provided meaning that became essential in his work.  The interactions
with other team members mostly involved communicating with the Biostatistician.  However, it also included interacting with
the other clinical team members, such as the MD in charge of the project.  The Biostatistician and Bioanalyst worked together
closely in analyzing and producing report tables and graphs.  Even though the meaning of the statistics is in the domain of the
statistician, it often ended up with the Bioanalyst needing to interpret their instructions to fill in the gaps.  This multi‐faceted
aspect of the job kept David interested in the work which sustained and rationalized his long commute for 12 years.

3
Growing within the Job
Although the data kept David interested, he did explore technical aspects of the job as well.  He continued to develop his SAS
programming skills by taking some database design courses at U.C. Berkeley Extension.  This gave him the opportunity to
work on several Oracle database projects.  He also was part of the initial Rx/Clinical development team, a joint venture
between Oracle and Syntex that led to Oracle Clinical, the leading clinical trial database management system used in the
pharmaceutical industry.
He began to take on management responsibilities, managing both people and projects at Syntex.  This continued on in his
career at Chiron in Emeryville.  He modestly attributed the management of people as being an easy job because the people he
worked with were capable and good to work with.  Since he had a good understanding of what it took to perform as a
Bioanalyst, he was able to identify people who had the right balance of research and interest in the data, along with the
technical programming skills.  It was a combination of having the tenacity to understanding the clinical aspects of the data
while having the technical skills to deliver analysis.  This was what David had strived for himself and was what he looked for
in forming the teams which he managed.
David is now the Associate Director of Bioanalysis at Novartis (formerly Chiron).  He is very proud of the team that he put
together since he started at Chiron.  Davidʹs first goal at Chiron was to establish a standard set of reporting macros which
would handle the standard CRF (Case Report Forms).  He decided to have his Bioanalysts balance their workload of
producing the day‐to‐day analysis and reporting work with developing and maintaining a standard library of macro software.
The standard software mostly focused on generating safety summaries since the efficacy data usually varied too much
between projects.  The difference among studies didnʹt lend itself to standardization.  He proceeded to assign Phil to work on
Lab data, Frances to develop macros for Adverse Events, Rob to work on Demographics and Conmed while David himself
worked on the Dosing information.  It was a management style that allowed him to participate in the work firsthand, while
motivating the team to develop software.  This was all implemented on top of the normal study analysis work that they had to
do.  He enjoyed working on his macro component which organized dosing information into a dosing analysis file and then
joined this file with time‐dependent events in a study.  This allowed integrating a subjectʹs dosing experience with other study
data such as adverse event and efficacy data.  For example, an adverse event can occur at any specific time during the study.
His macro would then merge this data with the dosing information and added variables such as the exact dose, the
cumulative dose, time since last dose, etc...  This was derived in association with the adverse event of this event.
Davidʹs approach to developing the macro system was to standardize any area where the potential use outweighed the
development and validation costs.  Having a standard macro system available provided for consistent analyses across studies,
projects and output.  It also prevented the programmer from having to do repetitive tasks.  This allowed them to focus on the
unique efficacy aspects of each study.  It made the job easier and more efficient for the Bioanalyst.  His team was also more
engaged and interested since the work was more dynamic and became more like a unique puzzle that needs to be solved for
every study.
It took a year to develop the 1st version of the software with much of the teamʹs efforts focused on the macro system without a
lot of competing study analysis work.  Later on, it took more time to implement subsequent version releases since the
programmers usually had project work that took precedence over the standard macro development.  David thinks however
that this was a more cost effective approach.  By giving the development efforts to the senior programmers who work with the
analyses themselves, the development of software was implemented by the same individuals who understand it the most.
David has a low key approach to managing his people.  He sets out goals and expects his people to work conscientiously and
autonomously.  He does not see himself as having a draconian style but rather a gentle coach approach.  David performs peer
reviews and makes suggestions but in general, leaves his people alone.  He sees that it is this freedom that allows the talents of
each individual to thrive and discover the unique balance of various skills to be a successful Bioanalyst.
CONSULTING SAS PROGRAMMER – GENE
Being resourceful and learning new things will keep you from
becoming stagnant and become successful as a SAS programmer.

Back in the Day
Geneʹs introduction to computers and technology started back in high school in the 70ʹs when he used the Texas Instrument
calculators that allowed him to program equations.  He then learned assembly language and machine code on DEC PDP‐11
and Zilog Z‐80 microprocessors.  Gene enjoyed working at the machine level of these 16 and 8‐bit machines because it taught

4
him the fundamentals and rigorous approach towards programming, including debugging programs.  He then progressed
into learning the BASIC language.  In addition to Geneʹs disposition towards problem solving which attracted Gene towards
computers, he also had interest in becoming a ʺdoctorʺ so he started his undergraduate work at Johns Hopkins in 1980 on a
degree in Biomedical Engineering.  This combined his clinical aspirations with his analytical, research‐oriented, engineering
ambitions.
The university setting, including summer jobs, gave Gene experience working on research projects.  Even though he spent a
lot of time in the lab working on animals, technology was ever present.  For example, the research labs had a Radio Shack
TRS‐80 computer controlling a dogʹs heart rate.  The combination of technology as applied to medical research was fascinating
because it was very ʺFrankensteinʺ.  Similar to how tinkering with early 8‐bit computers gave Gene the fundamentals of
software development, the laboratory he worked in gave him a foundation for medical research which later aided him in his
work on clinical trials.
Although he did not use SAS yet, Johns Hopkins and his graduate work at Case Western Reserve University did allow Gene
to work with BMPD.  This was another statistical software package at the time which allowed him to run statistical models
such as on ANOVA, T‐TEST which were in routines similar to SAS PROCs.
The First Job
One of the first jobs that Gene started to work on after his Masters degree in Biomedical Engineering was working as a Data
Manager in Los Angeles for a non‐profit organization named Los Angeles Regional Family Planning Council.  He worked on
projects dealing with clinical trials on contraceptives such as the IUD and non‐latex condoms.  Gene worked closely with the
data in a role as a  DBA/Data Manager using dBase III with tasks such as defining the database structure and setting up data
entry screens.  He was also introduced to SAS but had limited resources since there were no other SAS programmers in the
entire organization.  He therefore referred to his manager who had a statistical background, but was limited in SAS
knowledge and he also used SAS reference manuals.  Gene enjoyed learning programming on his own and purchased
additional SAS manuals directly from SAS Institute to teach the SAS language to himself.   .
As a Database Manager, Gene worked closely on data discrepancies such as programming edit checks and the process of
transferring data from dBase to SAS via flat ASCII files.  Once he had the data in SAS, he was able to generate descriptive
statistics using PROC MEANS, FREQ and UNIVARIATE.  The programming practices being conducted were not as formally
structured as in a typical clinical trial.  As a policy, permanent analysis files were never saved, but instead the same SAS
program would import the source data, create temporary analysis files, and directly generate statistical reports .  At this point,
Gene only dabbled in SAS and it had not yet become his main job.
After leaving LA, he moved to the San Francisco Bay Area to work for a medical device company dealing with laser eye
surgery named VISX.  He sought out this new position as a biomedical engineer, since it matched his college education.
Although he did initially accomplish some engineering improvements on their product, his background in working with
clinical data ultimately dictated his role at VISX.   Since Gene had been working as a data manager, they had placed him in a
position working closely with their DOS‐based Paradox database with analysis in SAS.  He continued working on the data
discrepancy management which was then exported to SAS for analysis.  Since this medical device was VISXʹs major product
and its major competitor, Summit Technologies, was developing a similar product, there were tremendous timeline pressures
to get the data submitted to the FDA for approval and beat their competitor to the open market.  So VISX decided to hire SAS
consultants to assist in achieving this goal.  Although marketing approval for VISXʹs product was virtually completed in
Canada and Europe, they were still in the process of getting approval in the USA and therefore were submitting the clinical
trial reports to the FDA.  Part of Geneʹs responsibilities was to guide the SAS consultants in their job.  He was not their formal
manager but he worked closely with them since he understood the meaning of the data and had some experience with SAS
programming.  He could bridge the gap between what topics the statisticians wanted to report on and how SAS programming
could accomplish these tasks.  This was an eye opening experience in that for the first time, he discovered that there existed
such a job where you can program in SAS 100% of the time as a job!  This intrigued him since he did not care for the
administrative aspect of the jobs he had seen.  These SAS consultants would just come in, focus on their work and were not
involved in as much meetings or office politics.  These guys were ʺdo‐ersʺ not ʺtalkersʺ.  They did not have administrative
tasks such as dealing with yearly performance reviews and were just there to do a specific job.  Gene saw this as a refreshing
alternative way of working.  He also liked how these consultants had opportunities to experience how different companies
operated since they did not stay at one company as long as permanent employees.  This variety of work kept these consultants
on their toes and prevented them from falling into a rut, with boredom and stagnation.

5
This insight encouraged Gene to continue to learn more about SAS through the use of the few SAS manuals he had access to.
He also learned by seeing sample code that these consultants would share with him.  Gene was now spending 50% of his time
working on SAS which was more than he had ever done before.
Transition to Consulting
There were corporate challenges at VISX which lead to layoffs.  This and other management turmoil lead Gene to try out the
consulting world starting with work at Roche Biosciences.  It started out as a 3 month contract which is typical for an initial
contract.  This introductory period allowed the company to evaluate the consultant to see if it worked out without making a
big commitment.  If things went smoothly and there was work to be done, it was normally extended.  Gene worked on the
precursor to Oracle Clinical known as Rx/Clinical which is the clinical trials relational database jointly developed by Oracle
and Syntex, which later became Roche Biosciences.  Even though he started out working in the role as a data management,
Gene grew into the position of a SAS programmer and continued to work as a consultant at Roche for three and a half years.
This was where he learned the majority of his SAS programming skills.  During these same years, Gene noticed that there
were some individuals in this large organization who began to have a ʺDMVʺ mentality.  After years of working in a
bureaucratic organization, they lacked the desire to learn new things and became less motivated.  Some of his colleagues were
in the same company for tens of years.  He began to see how this stagnation crept into his work routine as well, even though
he was a consultant.  This realization woke Gene up to the reality that perhaps he was also falling into this stagnation, and
keeping true to his original reasons for becoming a consultant, he decided to make a change.
Gene ventured into a short contract with Quintiles Pacific down the Peninsula in Mountain View.  This was the first time he
worked in a Clinical Research Organization (CRO) which was different from his experience with a pharmaceutical company.
His initial thoughts were that since it was a service organization, the work would be varied since they were servicing many
different clients at the same time.  It turned out however that many clients rely on the CRO to dictate the standards and the
way the work was done.  It therefore turned out that the work was still done mostly in the same way across different clients
and projects.
The desire to learn new things and work in different environments drove Gene to continue into other projects.  He had heard
from other SAS consultants that finding jobs on your own was the way to earn the biggest salary.  Despite this fact, Gene
relied on job placement firms such as Trilogy and ASG to land him new opportunities.  Gene preferred working in this
manner because he relied on the marketing resources of these firms to find him the projects so he could just focus on ʹdoing
the work and not trying to find the workʹ.  If one is lucky, there is always something new and interesting to learn within each
work environment.  At Pharmacyclics, he worked with the Trialex System which was a browser based thin client software to
manage reports and analysis files he created using SAS.  Now living in North Carolina, his current project is for Schwarz
Bioscience, which is actually based in Germany.  He however works at home most of the time connecting to servers in
Germany.  When Gene started, they did not have cube space in their North Carolina office, so the arrangement was for him to
connect via his cable modem from home and work through a remote desktop within a Citrix environment.  Most of the time, it
worked well but once in a while, his keyboard would spontaneously switch to a German style keyboard and his Ultraedit
editor would create unexpected characters so he would have to log out and back in to use an English keyboard again.
Different organizations have different approaches towards validation of SAS programs.  This is partly due to varying
interpretations of the regulations and also due to how different managers and organizations function.  At this current project,
Schwarz Biosciences has an approach of validating all the output 100%.  This means that there is an independent programmer
who would produce the same numbers in a separate SAS program stored in a separate SAS dataset which is distinct from
those that are meant to be submitted to the FDA.  This means that there is a separate program that performs a PROC
COMPARE to ensure that the two sets of numbers are identical before it is deemed ʺvalidatedʺ.  When Gene first started, he
primarily did the duplicate validation type programming.  Now that he has been on the project longer, he is doing more of the
original programming that will be part of the submission.
Since he works remotely, Geneʹs main method of communicating with his coworkers is through email.  Ninety percent of the
time, his email and communications are dealing with detailed information such as data, file, and variable names.  He does
recognize that at times, it does take a little longer to describe or show someone something in email whereas if he were to be
physically in front of them, it would be faster.
Resourceful Reinvention
Gene has found many creative and resourceful ways to learn and reinvent himself as a SAS consultant.  Even before he started
working professionally, his interest in 8‐bit microprocessors and working at the electronic circuitry level coincided with his
tinkering tendencies and attention to detail personality.  This inclination to focus on the details grew as he worked with data
discrepancies.  If Gene were to find one data issue, it would bother him to just leave the rest alone.  He has to then investigate

6
the rest to ensure that there are no such problems occurring elsewhere.  There is a certain satisfaction and comfort knowing
that he can ferret out all the discrepancies that exist in a database. An inclination to focus on details also helps in debugging
SAS programs created by others.
He did not attend SAS training courses.  Instead, Gene gravitated towards getting his consultant firm to pay for the SAS
reference manuals he requested.  He actually appreciated the cost effectiveness of user manuals since it is a continuous source
of knowledge that can be referenced over and over.  Good reference manuals had sample code that could be used as templates
to algorithms in real world applications.  Gene started his own personal electronic library of sample code that he refers to on
occasions.  This process started in his early days when he first started working with SAS consultants prior to him becoming a
full time SAS programmer.  Since then, he continued adding to it from other programmers, including original algorithms he
came up with and code that he acquired at SAS conferences.  Regarding SAS conferences, he sees SUGI being the biggest and
the most expensive.  There seems to be a larger representation of more seasoned SAS programmers and managers that attend
SUGI as compared to other SAS conferences.  He sees it as not necessarily focused on the Pharmaceutical industry so it is only
by chance to find a paper with substance and relevance.  Gene prefers the smaller regional conferences or PharmaSUG where
there is more diversity of attendees and the focus of the talks seems to be more relevant for him.  Recently, he had shared his
original SAS applications as a speaker at these conferences.  Gene is constantly sharpening his skills and looking for insight by
these many resourceful approaches.  It is a Darwinian world where if he sharpens his tools and constantly reinvents himself
by learning new things, he would survive and thrive as a SAS programmer.

STATISTICAL PROGRAMMER ‐ SUZY Q
There are many career paths. Sometimes, it is the unexpected and
unplanned ones that turn out to be the path that best fits your
personality and talents.

In the early 1960ʹs when Suzy went to college, they did not have computer science as a major.  Suzy majored in mathematics
for her first two years at UC Berkeley.  She found upper division math classes rather difficult and decided to switch to
psychology, keeping math as a minor.  Psychology was a very different discipline compared to mathematics but it was very
inline with her interest in teaching.  Throughout her academic experience, there were no computer classes offered for liberal
arts majors.  The only technology used at the time for psych statistics classes was a giant calculator that looked like a
typewriter with a crank handle for the ʺenterʺ key.
Suzy graduated in June 1966 and planned to get a teaching credential starting the following fall.  During that summer, she had
plans to work as a cocktail waitress in Tahoe.  Her father did not think that this was a fitting job after all her education.  He
therefore contacted a friend to arrange for an interview which resulted in an internship job at IBM.  Suzy was overwhelmed at
first during training since there was a group of 41 summer interns and she was the only female.  This was her first
introduction to computer programming which included languages such as COBOL and FORTRAN.  The programs were
executed on an IBM 360 computer.  She used a terminal which ran IBMʹs early version of DOS that pre‐dated any PCs or
Microsoft operating systems.  This job was an eye opener for Suzy since she was fascinated with technology and
programming.
After that summer she continued on her career path to become an elementary school teacher.  She discovered that the student
teaching program at Berkeley was not fully challenging her so she quit.  The internship position that she held in the past lead
Suzy to apply for a full time position with IBM as a Systems Engineer.  The job entailed doing both programming and
operating system upgrades along with enhancements for clients such as Kaiser Aluminum and the SF Chronicle.  Suzy taught
programming classes for IBM to clients in COBOL, RPG, and Assembler Language.  Suzyʹs husband served in the military
during that time so she traveled with him while juggling programming jobs and substitute teaching.  Once they arrived to the
San Francisco Bay Area, Suzy started to work for Bechtel in their corporate IT department as an operating system
programmer.

Suzy took some time off to raise a family before she re‐entered the work force on a part‐time basis.  She taught Assembler
Language programming at Laney College for a couple of years.  This was rewarding but it was also frustrating since her
students struggled to get computer jobs after completing their programming classes.  They had to have 2 years of computer
experience before they could get a job in the field, so it was very difficult getting that initial foot in the door.  After her

7
teaching position, Suzy worked for a freight company where she started out doing data entry.  She then obtained a promotion
to a programming position shortly after.  In this job, she was responsible for producing listings and summary tables.  The
work kept her challenged but the data was very dry.  She had an interest in science and medicine and wanted to work in the
new biotech industry where the data dealt with human clinical trials.
Suzy then enrolled in a masters program at Hayward State University to study statistics.  This enabled her to gain the
credentials she needed to work in the biotech industry.  This was her first introduction to SAS.  The University also taught
SPSS and BMDP software for statistical modeling.  She enjoyed the fact that the classed were small with only between 20 to 30
students per class.  This increased the interaction between students and professors.  She was originally planning to become a
statistician but realized that most companies require a PhD in statistics to function in that role.  Her degree was more suitable
for a job as a bioanalyst or SAS programmer.
Her first position after graduation was working for XOMA as a statistical programmer.  She attributed her masterʹs degree to
helping her obtain this position.  The programming experience that she had in other languages also helped.  This is where she
learned about the ins and outs of clinical trials while performing analysis to produce tables, listings and graphs.  She learned
to structure her work and optimize programming by creating analysis files and working more with SAS macros.  She attended
SAS classes and learned from other senior SAS programmers who worked there at XOMA.
Suzy then moved to Genentech where she worked as a senior SAS programmer.  She continued to learn new skills from SAS
conferences and the additional classes she took.  However, she found that the best way for her to learn new SAS skills was to
work with another experienced programmer.  Suzy is now doing work in the area of electronic submissions and Case Report
Tabulations.  This job utilizes her knowledge of clinical data, SAS, teaching skills, and the ability to work with diverse
programming groups at Genentech.  She enjoys being involved with projects where she can help to create the documentation
for reviewers and deliver a user friendly submission to regulatory agencies.  Upon reflection, there were two key moments for
Suzy during her career that was pivotal.  The first moment included taking the summer intern job at IBM and the second was
getting a masterʹs degree in statistics.  She has been fortunate to have found a great job that combines her various interests and
talents.

TELECOMMUTE PROGRAMMER ‐ ANGELA RINGELBERG
Communicating effectively while adapting to changes are key
attributes to becoming a successful telecommuting SAS programmer.
Angela earned a computer science degree in 1986 at the University of Mobile Alabama.  She did not program in SAS during
school, but did use PL1 as the primary programming language.  She also did assembler programming and did not apply it
towards statistical models such as in SAS.  When she graduated, it was difficult to get a job since she was caught in the bind of
not having the necessary prerequisite experience.  Angela had wanted to do something related to her technical training in
computers so she started to work through temporary placement agencies.
Angela started out as a data entry clerk for McDonald Douglas in Phoenix, Arizona.  She continued to be shuffled around on
various temporary projects doing data entry.  These jobs were not within any specific career path or industry since the
placements were more entry level.  She then started to work through Jean Simpson, a local small agency in Shreveport, LA,
which placed her at Boots Pharmaceutical.  It was another data entry position but after three months on the job, she
progressed to become a SAS programmer.  She was able to accomplish this through talking to various people in the
organization and in particular, the biostatistics and data management departments.  Her first introduction to SAS
programming was doing edit checks.  This was related to what she was doing in that it included algorithms which check for
the accuracy of the data which she worked with during her data entry position.   Although she did not work on analyzing the
data statistically, the data management tasks in conjunction with using the Clintrials database, gave her a better
understanding of clinical trials data.  Her programming tasks expanded into programming ad hoc requests for patient listings
and data listings.  Most of the knowledge was obtained on the job but she did also take some classes from SAS Institute which
taught her more about SAS macros and SAS/Graph.  Angela stayed at Boots for five years and worked her way up to
becoming a supervisor.
Her husband then received a transfer in his job to Southern California at Edwards Air Force Base.  It was about two hours
away from Los Angeles but it was a smaller and more isolated community.  The closest biotech company was Amgen but that

8
would have been a two and a half hour commute, so that was out of the question.  Even though she was in California, Angela
received a request from her former employer at Boots Pharmaceutical to work on a CANDA project.  At the time, many
companies were preparing a computer aided new drug application so that the FDA could review the information through the
computer.  It was a boon for programmers because many companies needed this solution.  The problem was that each
company had their own CANDA which made it challenging for FDA reviewers.  There was a large learning curve for
reviewers to use CANDAs between different companies.  As a result, this method is no longer used but it did present an
opportunity for Angela to work remotely at that time.  She was able to use her own PC to log into the remote machine.  The
employer even gave her SAS locally to do additional development.
Angela began to explore other telecommuting projects through the placement firm NovaTech.  She worked on projects for
Knoll Pharmaceutical, Quintiles, Norvatis, and Norfolk Railroad among others.  It worked well since she was able to do this
job at her home.  She began to master the art of telecommuting.  Angela was then known as the queen of email.  This was her
main form of communication in addition to the phone.  She worked for Novatech for six years.  Near the end, she picked up a
project for a CRO named PharmaNet.  She was a contractor at first working remotely since Pharmanet is headquartered in
New Jersey.  They had delivered to her a machine and a printer with all the security and software pre‐installed.  With a DSL
connection, she was able to log on via the VPN and she was able to do work from then on.  There were some challenges at first
since she had to sometimes wake up early to attend 6am meetings Pacific Time which was 9am on the east coast.  She
primarily communicated with the project manager and statistician remotely.  All the annotated CRF were scanned
electronically and emailed to Angela.  If she needed to see it on paper, she could just print it out.  She continued to do some
validation programming but the majority of the time was spent developing summary tables, listings, and graphs.
Most of the meetings were done over the phone.  However, Angela did also experiment with Net Meeting and MShow which
allowed desktop sharing.  Even though she started as a consultant, after 5 months, PharmaNet hired her on as a permanent
employee.
Angela has a knack for working as a telecommuter.  She feels that one of the primary skills needed is to have excellent
communication skills.  This can make or break the job since everything has to be communicated though the phone or email.
She also has the passion for doing this since it gave her better control over her schedule and better quality of life by being
closer to her kids.  It also requires self‐discipline since she has to construct her own self imposed 8 hour work days without
supervisor enforcement.  One skill she picked up was to keep tabs on her projects and communicate her status to various team
members constantly.  That way, they would know where she is at and send her the right amount of projects at the right time.
Among these skills sets, she also had to gain a certain level of trust among her co‐workers and supervisor.  This was
established at the beginning and worked out under the initial contract.  During that trial period, if things didnʹt work out,
PharmaNet could easily end the contract without any legal difficulties.
Angela has a good combination of communication skills along with being very adaptable in her work.  She made the pivotal
move from the data entry clerk into SAS programming by communicating to the right team.  She then transitioned and
adapted to the various programming requests that came her way even though she only had experience in data entry.  When
she was relocated to California to a small community, this outpost did not deter her from doing her work.  She was able to
adapt and re‐invent herself as a telecommuting programmer.  The technology in telecommunications combined with her
talents enables Angela to be a productive and valuable resource no matter where she is located.

CONCLUSION
The more examples you see on how individuals become clinical SAS programmers, the more unique they appear.  The stories
of the four individuals in this paper are derived from a longer set of stories within the book Becoming A Clinical Trials
Programmer.  The book will explore in greater detail career paths along with technical information based upon valuable real
world lessons.  There is no one optimal path that you have to take in order to be successful in this career.  The stories shared in
this paper show how diverse the individuals are in the way they took their steps.  Even with one individual such as Suzie Q,
many turns were taken in her career before settling in this work.  Part of the reason why this job is so diverse is due to the fact
that the skill set required varies as well.  There is the domain knowledge that is needed to understand the clinical data.  This is
combined with the technical skills of a computer programmer.  It is the combination of these skills which creates such a
diverse set of requirements.  There is a certain level of aptitude that is required to perform well. The individual also needs to
be interested and therefore maintain the tenacity necessary to overcoming challenges in navigating through the career path of
a SAS programmer within the Biotech and Pharmaceutical industry.

9

REFERENCES
SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in
the USA and other countries. ® indicates USA registration.
Other brand and product names are registered trademarks or trademarks of their respective companies.

ABOUT THE AUTHOR
Sy Truong is President of MXI (Meta‐Xceed, Inc.) They may be contacted at:

Sy Truong
1751 McCarthy Blvd.
Milpitas, CA 95035
(408) 955‐9333
sy.truong@meta‐x.com

Career path for sas programmer

More Related Content

What's hot (20)

Similar to Career path for sas programmer (20)

Recently uploaded (20)

Career path for sas programmer