f



Re: Do this. Don't do that. Can't you read the signs? #4

A few years back I was working as a contract programmer for Big Pharma and
was actually asked by a manager to not use SQL in my coding because none of
the programmers in their group knew it. Needless to say, I did not work for
that group much longer...


-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
Nathaniel Wooding
Sent: Friday, August 14, 2009 11:31 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Do this. Don't do that. Can't you read the signs?

Paige

Then, there was a co-worker who refused to take the time to learn our
current word processor and, instead, typed his
memos using Excel or whatever our spread sheet was.

Nat Wooding

-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Paige
Miller
Sent: Friday, August 14, 2009 12:55 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Do this. Don't do that. Can't you read the signs?

On Aug 13, 9:20 pm, "Lou" <lpog...@hotmail.com> wrote:

> 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
> SAS/BASE.

To add to what Lou writes, I have met people similar to these that Lou
describes, who think that SAS has a dozen statements, etc.

I have worked with these people on occasion to help them improve their
SAS code. And sad to say, many many many of them (I'm going to guess
50% in my experience) either do not want to learn better ways to do
things, or they are not capable of learning new things. This is true
not only in SAS, but in other software that I have supported over the
years. You simply can't talk these folks into using a better method.

I have seen people write a datastep of 12 or 15 lines, simply to
compute sums down a column in BY groups. This person didn't want to
use PROC MEANS, or he couldn't get his brain to understand it, or he
was unwilling even to make the effort. And why should he, his datastep
worked perfectly well.

I have shown people how to use a specific function to achieve a
result, and they say "Oh, that's too complicated!" Instead, they will
create the most convoluted, inefficient, impossible-to-read code to do
the task.

The list of frustrations is long, and while I admire the idea behind
creating a document of best practices, there is a percentage (which as
I said is 50% or more in my experience) of people that will ignore
best practices. The people who are willing to learn will learn. Those
that are not willing to learn, or not capable of learning, will go on
with their inefficient methods; nothing I have ever been able to do
could shake them out of their "no learning" mode.

--
Paige Miller
paige\dot\miller \at\ kodak\dot\com
CONFIDENTIALITY NOTICE:  This electronic message contains
information which may be legally confidential and or privileged and
does not in any case represent a firm ENERGY COMMODITY bid or offer
relating thereto which binds the sender without an additional
express written confirmation to that effect.  The information is
intended solely for the individual or entity named above and access
by anyone else is unauthorized.  If you are not the intended
recipient, any disclosure, copying, distribution, or use of the
contents of this information is prohibited and may be unlawful.  If
you have received this electronic transmission in error, please
reply immediately to the sender that you have received the message
in error, and delete it.  Thank you.
0
peakstat (88)
8/14/2009 5:42:13 PM
comp.soft-sys.sas 142828 articles. 3 followers. Post Follow

1 Replies
420 Views

Similar Articles

[PageSpeed] 34

"Richard Read Allen" <peakstat@WISPERTEL.NET> wrote in message
news:008201ca1d06$8f367300$ada35900$@net...
> A few years back I was working as a contract programmer for Big Pharma and
> was actually asked by a manager to not use SQL in my coding because none
of
> the programmers in their group knew it. Needless to say, I did not work
for
> that group much longer...

Apparently, whoever wrote the document that sparked this discussion didn't
either - one of the "requirements" is that every data and proc step end with
a run statement.



0
lpogoda (325)
8/15/2009 1:08:57 AM
Reply: