Gosh, a nice interesting discussion and I was too busy "getting it done." this week :-)
So here it is at 10PM at night and I guess I'll contribute and hope that the discussion continues.
OK, I have a new job and the pressure is very much on getting it done, but I think that the skills one brings to the job makes a huge difference...we had a new employee orientation and there was talk about whether one learns from others, from experience, or from education, and I have realized very much over the past few weeks that I learned from others, mainly those of you on SAS-L who responded when I had time last year! And I learned a lot last year, and miss that time *with all of you* so much...
BUT, just as the Covey training states, one must make time not only for the urgent but for the important but not urgent, and that's what I'm seeing in some of the other programmers- if you focus on urgent all the time (and it is a team leader's job to try to make you do so, so don't blame him), then you miss out on learning the important but not urgent.
So I find myself glad that I spent the time last year on SAS-L (and I did do work as well, but just not intensely as this present job). It is people that are so rushed by team leaders that don't spend time learning new things because they are rushed by their team leader to get stuff done, but it is also their own responsibility, such as to sign on on weekends but NOT do the urgent task but rather do the long-term learning that will lead to doing the urgent tasks (which are never ending, it seems, where I work currently) in a more efficient way.
So do I code differently than my co-workers? I think yes, in that I use SQL more and BASE SAS less, and more functions, and much more ODS, especially in terms of gathering pieces of output and putting them together in reports.
It is the balance of the short term need- which must be done, and the long-term strategy- to accomplish the job in an "easier" way- that is the challenge of programmers. Read Steven Covey- if you always spend your time in the urgent, and never in the non-urgent, but important, sector, then you never advance.
But also there is the need to be able to distinguish between what is *important* from what is not; I'm not sure this can be taught!
--- jrburtonsaspro@GMAIL.COM wrote:
From: John Burton <jrburtonsaspro@GMAIL.COM>
Subject: Re: Do this. Don't do that. Can't you read the signs?
Date: Fri, 14 Aug 2009 13:05:39 -0400
"Data _null_;" and Lou,
I hear ya, loud and clear.
What gets me is that the folk hiring clinical research
programmer/analysts usually don't even care whether or not a candidate
knows how to program or knows SDLC or not.
It's not just clinical research jobs, either. It's a whole lot of
"end-user" shops in almost every industry. Over the past 10+ years,
I've been only in shops that are outside of the control of the IT
Departments. None of the managers approached jobs or projects as data
processing. Essentially, the attitude was "get her done!", not "get
her done!" properly, but just "get her done!" ASAP, right or wrong!
AnalyticBridge, inCircle, Linked-In, MedZilla
On Fri, Aug 14, 2009 at 9:50 AM, Data _null_;<email@example.com> wrote:
> Thanks for the input Lou.
> I was hoping to get the SAS-L community involved in the review of this
> document as I believe the SAS-L participant or lurker to be a better
> informed SAS user than most.
> On 8/13/09, Lou <firstname.lastname@example.org> wrote:
>> ""Data _null_;"" <iebupdte@GMAIL.COM> wrote in message
>> > The clinical trails SAS programming community is asking for input on
>> > this document.
>> > http://tinyurl.com/q3gwmy
>> > While I don't disagree with the effort I find this documents to be
>> > inadequate. Not that I can do better either, that's where you can
>> > help.
>> > I have read many documents (sugi papers, etc.) like this over years
>> > and have always been unimpressed. They are either too general or too
>> > specific or just wrong. I often think they are written by folks that
>> > don't use SAS.
>> On the contrary, they're often written by people who use SAS in clinical
>> trials. Unfortunately, most programming in clincal trials is incredibly,
>> unbelievably, amaturish, where it's not downright lousy.
>> Most so-called programmers in clinical trials are lousy at programming.
>> Many arrived at programming after starting out in some clinical aspect of
>> clinical trials and never learned anything about data processing. Many are
>> statisticians by education and/or job title, but again know little or
>> nothing about data processing. Almost none of them have ever opened a
>> printed manual, and almost all of them don't even know you can type "help"
>> or press F1 and find answers to almost any work-a-day SAS question they may
>> have in a matter of minutes.
>> Almost everyone I've interviewed in the last 10 years in the clinical trials
>> field thinks that SAS has maybe a dozen statements, 3 or 4 procs, maybe 2 or
>> 3 formats, and the more creative of them will guess at around a dozen
>> functions. These same people invariably estimate they know 80% - 90% of
>> With apologies to the author(s) of the document you cite above, this lack of
>> knowledge is reflected in the attempts to write standards documents. This
>> particular example isn't even written in reasonably decent English.
>> > So, can we "SAS-L" help to make this a better document. I expect you
>> > all have opinions and welcome your input. And expect that the CT SAS
>> > programming community will too.