Post by sasproI am technically adept and i work in the pharmaceutical industry but
my speed is a little slow when it comes to programming.
How can increase my speed so i can do quality work in a higher
quantity in a shorter time.
Please you're sincere output will help me out of a life and death
situation.
I'm currently the director of clinical programming at a smallish, rapidly
growing, pharmaceutical partnering company. I've been a SAS programmer for
something like two decades (I started when releases were named by the year
of the release, before version 5) and made my living by consulting as a SAS
programmer for a dozen years in a variety of fields (defense contractors,
insurance, human resources, marketing of consumer goods, marketing of
pharmeceuticals, inventory control, package tracking, data warehousing,
etc.). I think I know some of the ingredients that contribute to making a
person a good programmer.
1. You're brain has to work the right way. Programming doesn't suit
everyone, anymore than everyone can become a virtuoso on the piano. It
sounds like you're currently employed as a programmer and interested in
improving your skills, so presumably you have this one knocked.
2. Learn to type. That means using all eight fingers and both thumbs, and
being able to do so with reasonable accuracy without looking at the
keyboard. It means also being able to pull it off without looking at the
screen or the keyboard as you type, at least some of the time.
3. Read the fine manual. Get yourself a PRINTED copy of the manuals (spend
your own money to buy them if your company won't spring for a set) for the
base system, and when you're not otherwise engaged, read them. Start on
page one. Take the pages in order. Help screens aren't the same. There's
a lot of great stuff in the manuals. It won't all stick with you on one
reading, but you'd be surprised at the bits that settle into the nooks and
come to the forefront when you need them. If you find the manuals boring,
you're not cut out to be a SAS programmer - look for another line of work.
4. When you encounter a problem that you don't know how to tackle, pull out
those manuals and look up possible solutions. Use the index. This doesn't
replace talking with your colleagues or posting questions to SAS-L, but it's
almost always quicker to look something up than it is to explain it to
someone else or posting a message here and waiting for a reply.
5. Unlike most people these days, I'd strongly urge you to look for just
about any solution other than writing a macro. Most so-called programmers
learn a few basic tricks and string them together endlessly in macros.
Better than 90% of the time, there are quicker (writing less code takes less
time), better (less code usually takes less time to execute) and more
elegant (simulataneously simple, transparent, and clever) solutions.
Besides, it's usually easier to write code to do a task than it is to write
code to write code to do a task. The other 10% of the time, a macro might
be the best solution, but something you noticed while looking for an
alternative will turn out to be a life-saver in some other pinch.
6. Comment your code liberally. If less than a third of your program file
isn't comments, you're not commenting enough unless there's ample
documentation elsewhere. Type each comment first, before you type the code
it describes. It helps clarify your thinking, it forces you to think about
what you're going to do before you've meandered into some unsalvageable
cul-de-sac. When you're done, someone else should be able to understand
what your program does (though not necessarily how it does it) by reading
the comments alone, without looking at the code.
7. The key to learning any skill is to practice. Practice every chance you
get. Search for chances to practice and things to practice on. If you've
mastered a particular problem in one way, look for different solutions. For
instance, I can think of four ways to use a FILENAME statement to point to a
particular file (there are probably more) and that doesn't count using the
filename FUNCTION. There is no one best way to do anything, different
techniques directed toward the same end each have their sets of advantages
and disadvantages.