LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (July 2002, week 4)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Fri, 26 Jul 2002 12:33:09 -0400
Reply-To:     "Goldman, Brad (AT-Atlanta)" <Brad.Goldman@AUTOTRADER.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Goldman, Brad (AT-Atlanta)" <Brad.Goldman@AUTOTRADER.COM>
Subject:      Re: Best Ways To Learn SAS?
Content-Type: text/plain; charset="iso-8859-1"

My thoughts are along the same lines. During a previous job\, I had a project manager who had a different outlook on problems than me. I wanted to get the problem done, in the time allotted. He wanted to get the problem done the right way, even if it took more time. And if doing it the right way meant taking time learning new techniques, so be it. Fortunately, no one understood what we did, so it was easy to stall management deadlines while doing R&D! The upshot was that I learned how to research programming problems, how to allow my curiousity to guide my research.

Many programmers are unconciously guided by the saying, "When all you have is a hammer, the whole world looks like a nail." If all you know is array processing, every problem looks like an array problem. If all you know is datastep processing, you will never take advantage of premade procedures. If all you know is SAS, you will never learn the great unix and perl approaches to problems, etc... The programs will work, but you will have never grown by doing them. It is important to view every new SAS problem as an opportunity to add more tools to your toolbox.

-Brad


Back to: Top of message | Previous page | Main SAS-L page