Getting Started
Introduction
Perl IDEs
History
Advice
Tools
Mini-Tutorial
Tutorial
Code Snippets

Resources
Top Sites
More Tutorials
Books
Magazines
Articles
NewsLetters
Mailing Lists
NewsGroups
Forums
User Groups
Talk Shows
Blogs
Clothing

GBIC >> Perl >> Advice >> Programming Focus Areas

Advice for Beginners - Programming Focus Areas
I get the same question over and over, "How do I get started in Perl?". This section provides a "cookbook" set of instructions and tips which should provide the answer for this question!

  • Getting Started
    A step-by-step process for getting, and learning, Perl. If you're a beginning programmer and aren't quite sure how to get started, just follow these 9 steps to get comfortable with your new role as a programmer.

  • Programming Focus Areas
    You'll be surprised to learned see that technical matters are not always the key to productivity. Follow these 15 rules to take you to the next level of programming.

Programming Focus Areas
The following rules are my own suggestions, to beginners and advanced programmers alike, on how to improve your programming skills. You'll note that some of them are generic learning techniques, not just programming-specific approaches.

  • Rule 1. You must code to get good at coding.
    Cross-training is a myth. You can't get good at running by jumping, and you can't get good at coding by reading. All the materials listed in the Step-by-Step above section are worthless unless you practice what you have read. This means code, code, and more code!

  • Rule 2. Memorization is your most productive tool.
    I hate it when my kids say "Dad, I can't quote the exact answer but I know where to look it up!". My personal philosophy is that as a programmer I want to create my applications as quickly as possible. When I have the syntax of Perl commands memorized I can whip through an application in record time. If I had to stop and look up the syntax in the user's guide for every line of code I wrote, I'd more than triple the time it takes to complete an application. The moral of this story is that when you are reading the manuals, read with the intent to remember exactly what you read, not just where it can be found!

  • Rule 3. Typing is Your 2nd most productive tool.
    I'm always amazed at my coworkers' comments on how fast I type. For me, to think it is to have it typed already. The value of this should be obvious. If you can't type efficiently you'll not only slow down how fast you record your ideas, but you'll also interrupt your creative process with the mundane task of watching your fingers single-stroke an idea. Have you ever noticed how distracting it is to listen to a slow speaker? Same idea applies to typing! You want your fingers to work as fast as your brain.

  • Rule 5. Use a Code Librarian
    Recreating code you've written before is the worst possible use of your time there is. Once you've written code, that can be used again, the put it away in a code librarian and use it over and over again.

    I recommend my own freeware code librarian, gbCodeLib. It supports multiple languages, is full-featured, comes with 1000+ code snippets, and provides revision control tracking of all changes - and more!

  • Rule 6. Focus, focus, focus - your time is limited.
    If your goal is come to speed as quickly as possible, then stick with the game plan of reading one or two books front-to-back while working every example they provide.

    It's all too easy to get distracted with online newsgroups, language forums, 3rd party tools, magazines, and other sources of training materials. The goal for now is get a foundation of learning skills, which will make expansion of your skills much easier down the road.

  • Rule 7. Start small.
    Remember to start with small coding projects and work your way up to more complex ones. The real goal of a small project should be to learn just a few coding concepts. Programming skills are additive and you will get more frequent, positive feedback if you tackle many little projects instead of a few large ones.

  • Rule 8. If you don't have a big project, get one!
    As soon as you're comfortable with the basic skills, then start a big one of your own choosing. Until you have a personal need for a capability of Perl, reading about it is like hearing about sex! You've got to do it to appreciate how great it is! Big projects have a way of causing you to reach the limits of Perl in a way that little projects don't. It is often the interaction of Perl elements which gives a programmer difficulty, and large projects provide more of this than small projects. Notice that the intent is not just to have a program with many lines of code, but to have a project that uses as many features of Perl as possible.

  • Rule 9. Use 3rd Party Tools.
    This follows from Rule 2. Often, a 3rd party vendor puts hundreds, or thousands of hours into his product. If he sells it to you for under $100, it is an absolute bargain. As a paid programmer, your job is to get the software completed as quickly as possible and at the lowest cost. When you charge $40-$75 an hour, you are treating your customer poorly if you spend hours recreating something that is already available as a 3rd party tool for less money than you would charge for your own efforts.

    I don't recommend the use of 3rd party tools until after you have mastered the basics of Perl and have had the experience of trying to create your own code to replicate a 3rd party tool. You'll appreciate it more that way.

  • Rule 10. Attend training classes wisely.
    I have a strong opinion about classes. You don't get the most from a class unless you have worked with the topic on your own before coming to class. So, if you decide to take a class, then I recommend that you wait until you have used Perl enough that you have a mental list of things you don't seem to understand. Then take a class and you'll get more out of it. If you go in with no prior knowledge, you won't appreciate what is significant or what is not.

  • Rule 11. Use Free Scripts
    There are two really good reasons why you should take advantage of the many free scripts that can be found on the web. First, another programmer will often code a function in a way that you haven't thought of yourself, thus giving you new insight into how to improve your own programs. Second, the whole purpose of writing programs is to accomplish a task. It can often take much less time to use an existing script, modified to your own purposes, than it would take to write the script yourself from scratch. Especially in those cases where you are a paid programmers, you owe it to your employer not to re-create code that is already available elsewhere.

  • Rule 12. Develop an informed, thoughtful opinion.
    When you're learning information, don't stop at just being able to replicate what you've read, or at just being able to apply it to your application. Some of the best study time you'll have is when you take the time to examine the code/technique you're using and attempt to take it apart. Ask yourself questions about what you know - do you understand it, or do you just know a few facts? Was the material you studied complete, or was it missing information on some facet of the technique? How does the next information tie in with what you already know? Does it replace or compete with what you already know? When should you use it and when is it the wrong approach to solving a problem? When you think you could teach it to someone else, then you've gotten a big step closer to full understanding.

  • Rule 13. Teach Someone Else.
    Ask any teacher and they will tell you that you don't really know what you know until you have to teach it to someone else. Reading gives you one level of knowledge and applying gives another. But neither requires you to sort it out in your head like explaining to a student what the technique is, why it is important, when to use it over other options, what the negatives are, and what it's strengths are. If you don't have someone to teach, then a) simply go to the USENET groups and try to answer questions or b) get a web site and advertise on it that you will answer questions for free - then stand by for the avalanche of questions.

  • Rule 14. Don't learn everything from one source.
    I am an avid Country Western dancer (after all, I am from Texas!). I've taken literally hundreds of lessons, from over a dozen instructors. What I found was that one instructor was able to teach me some steps, but didn't have the skills to teach others. Each instructor had his own viewpoint and by getting instruction from them all I was able to develop a clear understanding of what I was learning - seeing it from many different angles.

    The lesson applies directly to Perl. Read from several books, read from the USENET, read the available newsletters, read Perl documentation, and listen to as many instructors as you can. It will pay off in a significantly better understanding of the materials you need to know.

  • Rule 15. Keep moving through the study topics
    One mistake beginning programmers often make is to assume they have to completely understand one topic before they can move on to the next. The problem with this is that you can get stuck and spend more time on a topic than it deserves. Also, you will find that Perl topics often tie together. You might not fully understand how important it is to know that lists and arrays can be used interchangeably. It may not sink in how useful this fact is until you study the section on how to extract information from a text file. Understanding of the first topic sometimes comes from reading a second. You sometimes have to keep moving in order to find the information you need to make sense of what you have just read.