Date: Sun, 18 Dec 2011 20:32:48 -0500
Reply-To: Quentin McMullen <qmcmullen.sas@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Quentin McMullen <qmcmullen.sas@GMAIL.COM>
Subject: Re: SAS Career
Content-Type: text/plain; charset=ISO-8859-1
Interesting point, Mark.
To be honest, I haven't inferred much from the fact that SAS is
pushing EG. SAS has a lot of different types of customers. When I
went to SUGI for the first time (SUGI 25 in Indianapolis) I was
disappointed by the opening session. If I remember right, the keynote
was about Levi's using SAS to track shipments of jeans around the
country. Not a single line of SAS code was shown during the evening.
And I realized that SAS made a lot more money off of business users
than it does off of researchers getting by on Federal
grants/contracts. In my 15 years of programming in SAS, they've never
really *marketed* to me. And that's fine.
As a programmer, I haven't felt threatened by EG, in the same way as I
didn't feel threatened by SAS/ASSIST.
But I admit to being largely ignorant of EG, and I have not seen much
adoption of it in my world (academic research). I don't imagine it
being adopted much in pharma/biotech either (is it?). I've seen a few
talks on "EG for programmers" (most recently at NESUG), but haven't
been inspired to play with it much. And I guess I've thought of it
mostly as a tool for BI folks. Am I wrong about this? In which
fields do you see the use of EG growing and replacing
On Sun, Dec 18, 2011 at 4:10 PM, Keintz, H. Mark
> And what inference about the value of programming (of any sort) should we make from the big effort that SAS Institute is making in pushing Enterprise Guide?
> Let me rephrase that. Assuming (and I do) that this SAS initiative is an intelligent response to the labor market of its current and prospective customers, what does it suggest about the vision of those customers regarding the value of programmers? I've never heard anybody suggest that EG generates good maintainable code, one of the primary objectives of a programmer, yet its usage seems to keep growing.
> You could argue that the promotion of EG is an endorsement of the basic premise of the OP. I think there's more to it than that. But as to career implications, it just reinforces the advisability of getting some content or analysis expertise to leverage your SAS knowledge. - an idea that long predates our current environment.
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Quentin McMullen
> Sent: Sunday, December 18, 2011 3:05 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: SAS Career
> Interesting thread. I've been thinking about this over the weekend, and wanted to share a couple thoughts. In my time SAS programming, I've spent time both as an analytic/statistical programmer, and as a data management programmer, primarily in research settings (for profit and academia). I see what Jason wrote as mainly questioning the value placed on data management programming vs statistical programming.
> One theme I have seen replayed in many environments is that I think many people make is the mistake of thinking their own role is more intellectually challenging than others. Imagine a research team with a data management programmer, statistical programmer, statistician, and scientific investigator. I think it's common for the statistical programmer to think the data manager work is easy ("How hard is cleaning data?") and similarly for the data management programmer to look down on statistical programmers ("it's just PROC this and PROC that, not real programming."). The scientific investigator doesn't understand why the statistician takes so much time to develop and implement an analytic plan ("it's just some sort of regression, right?"), and once the analysis is done the statistician wonders why the investigator takes so long to write it up ("I've sent all the results and a methods section, all they have to do is write the words...."). To my thinking it's similar to the fundamental attribution error (psych). People know the complexity involved in their own work, and underestimate the complexity involved in the work of others.
> Another factor that can lead to a perceived devaluing of data management programmers is that the praise/glory/etc usually come at the end of a project, when a result is delivered (again, I work mostly in research settings). So here, because the data management work is early in the process, their work has often been completed (and
> forgotten?) long before the final deliverable is complete.
> Recognizing the above has in the past helped me accept times that colleagues have not been as enthused about my productivity as I have been. I think it's "natural" for people to under-value the work of others (of course the best managers overcome this tendency). As someone interested in SAS programming, expecting less external validation from others has allowed me to follow my own interests (which recently have tended more towards data management and less toward analysis).
> And if you decide to stick with data management programming and also seek glory, it can suggest an approach. You will find more celebration of data management programming if you work in an a place where the final deliverable produced by your company (or department) is a dataset. So that you are creating an end product (which is easy to value) rather than being part of the process.
> None of the above is to suggest that someone should stay in a position where they are under-paid, unchallenged, disrespected, etc. But I think it's helpful to set realistic expectations for how much praise you will receive from others, at the same time as you steer your career towards you area(s) of interest, and seek an environment where your contributions are adequately rewarded.
> Kind Regards,
> On Fri, Dec 16, 2011 at 5:13 PM, Curt Seeliger <Seeliger.Curt@epamail.epa.gov> wrote:
>> Jason wrote on 12/16/2011 01:20:26 PM:
>>> I just realized I have had a very stupid career all along. I became a
>>> programmer a few years ago because I heard SAS was a very good skill
>>> jobs were paid well. This is generally true. It allows you to find
>>> jobs relatively easier compared to other skills. But if you only know
>>> SAS programming, your career will go nowhere. People would only treat
>>> you as
>>> data "plumber": managing and processing the data and other low-level
>>> You will not move up in the corporate ladder if you only know SAS
>>> So SAS programming is considered a "low-value" skill. You need to add
>>> higher-value skills in order to excel at work. Other skills like
>>> analysis(SAS/STAT). A phenomena I observed over the years in the
>>> scene is most so-called statisticians would avoid doing low-level SAS
>>> programming work and only want to get clean data from SAS programmers
>> and do
>>> analysis work. These people are the ones who have strongest contempt
>>> programmers. They think they are smarter and SAS programmers are stupid.
>> So if
>>> you have good analytical talent, don't let that talent go wasted
>>> people step on you.
>> Ouch. Sounds like you've been stepped on.
>> What you've said about SAS is also true of other languages -- if you
>> know C or
>> C++, you're good for programming down to the metal. If you only know
>> BASIC, you're in management or marketing.
>> It's also true that most people benefit by 'educating' their
>> coworkers/superiors/customers about the value of the work you perform
>> for them. Rather than let people see you as 'just a plumber', show
>> them that you're a journeyman or nearly so. Talk to them about how
>> you overcame the technical difficulties. Plumbers do stuff I don't
>> feel comfortable attempting by myself, and I'm happy to pay them what
>> they ask, even if in the end it runs to $150/hr. If there are no real
>> technical challenges to your job, you'll find another job. But keep
>> in mind that there are many jobs that require an intelligent person who is willing to be bored.
>> Most importantly, though, enjoy the days.
>> Curt Seeliger, Data Ranger
>> Raytheon Information Services - Contractor to ORD