If your perl is half-decent, with the exception of not knowing packages and OO, then you are largely worrying over nothing. The beauty of perl's OO and packages is their tinyness. OO is just bless, @ISA, and a little bit of syntax. Past that, it's things you already know, mostly hashrefs.

I might have focused on that too much. The main thing is that there's just so much information available, how much should there be learnt, when is one "fit enough" to start on a project.

I can just start coding now, but perhaps I will find much better ways of writing the same code, I might have to rebuild/update a lot of my scripts, which would take time. Time I might have saved by starting well prepared.

That is kind of what I'm getting at.

---

1

If you take that attitude, then you'll never start coding.

Besides, if you keep reading you'll run into a lot of apparently (or actually!) contradictory information. There is no way to sort this out without having an experience base of your own to draw from. And other things that you'll read you will likewise not understand unless you have some experience under your belt. Finally all of the theory in the world does no good unless it becomes reflex, which again takes practice.

So there is a chicken and egg problem here, you don't want to start until you have the skills, but you cannot develop the skills unless you start.

The answer is to do all things at once. Be aware of what you don't know or don't know that well, and proceed. Be sure to re-evaluate periodically. Continue to learn, practice, read and grow. At some point this is the only way that I know to learn a practical skill.

However, if you can, it is good to make the first few projects that you do be things which are unimportant, so the inevitable mistakes are not a big deal.

You may or may not really save time doing that. The problem is that you understand things so much faster when you use them, or at least you do when your brain works like mine. So yes, you will rewrite things when you discover better ways, but you won't spend time scratching your head, not really getting it.

If at the end of a project, I don't know anything that I didn't at the beginning -- if I would have done it all the same way -- then it's a sure sign I didn't learn anything, and that's a bad thing.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Go with what I know, learn as I go

Learn as you go is the only sane approach. There is just too much knowledge out there, for you to decide what you need to know before hand. You end up filling your mind with useless details which ends up being discouraging.

My approach, "get the big picture first" and get a hold on the vocabulary and words that are involved. Then find a simple example which forms the basis of what you want, and go from there. Now you can start digging for details on how to deal with your immediate problem.

Arjen

It's like learning a natural language, say English. Do you wait until you learn all the English words and grammar before starting to use it? Of course not, just look at the kids.

Writing code is, in many ways, no different than writing prose. The best piece of advice I ever got in both cases is ot just start writing. Remember, in both prose and code, writing is an iterative process. You'll rewrite things -- maybe even several times -- before you get them the way you want them.

Also, the first few things everyone writes are crap. That's ok. Write crap that no one else needs to use, but that helps you; I cut my teeth writing horrible little automation scripts to handle some thing on my home Linux machine. They are embarrassing now, but I learned a lot by doing them.

Pick a problem, and see how much of it you can solve with the skills you have. Look up what you can't solve on your own, and ask the community for help when you're stuck. Then, go back and try to make it faster, more reliable, etc. Then, refactor into another Way To Do It.

For example: write a script that emulates the basic functions of the UNIX ls command. Now, do it with subroutines of no longer than 10 lines each. Now, split groups of subs out into modules (you might have to learn about modules to do that). Now, make those modules OO instead of exporting. At each point, update your main ls script to use the new system.

Exercises like this tend to teach you a lot, because you can solve a problem you already know a bit about (listing files), and you have a reference for what "correct behaviour" is (the ls command). Revising will make you see where some things are difficult, but more importantly, it will help you see a few different ways to do things, and what some of the tradeoffs are. If you do this with a few simple projects, then you can start on something a little bigger.

And remember, when you're done, it will probably be crap. ;-) That's OK: writing crap is how you get comfortable with writing, and as you get more comfortable, you write better. I've been coding in Perl for several years, and most of what I write is still crap -- but it's less crappy than it was when I started, and someday I might actually write good code. Very few people write truly good code.

I can see a snag though. When the boss says, "Yes, that's very good but what has the Flinstones got to do with it?".

Nod sagely and say, "Ah, all will become clear". And keep your fingers crossed!

Coding is the same. Build an outline. Figure out what the job is. Break that job into smaller concepts. Figure out how those concepts relate, and what the inter-dependancies are. That will tell you something about the data you need to pass between them. Work top-down and bottom up towards the middle, and know what the plan for each section is before you start. Draw block diagrams, and see how each block fits together with the others.

Document your design: both in your code, and outside of it. Six months from now, you'll forget what you were trying to do. Write comments first, then write code that matches what the comments say. Make sure the comments explain what you're trying to do, and not just how. Keep them up to date.

Example.

# Bad comment example
# get characters 5-14 of DIALED into $y
$y = substr($DIALED,4,10);

# Good comment example
# Extract the destination phone number from the dialed 
# digits field.
# Skip over the speed dial digits.

$dest_phone = substr($DIALED,4,10);
[download]

Finish reading the chapter on subroutines! Subroutines are arguably the most important idea in programming. Learning to break a big problem into sub-problems, and carefully solve each piece one bit at a time is an imporant life skill; and not just when it comes to programming.

Good luck, and keep learning! Keep asking questions; of yourself, and of others. The most important part of the learning process is to keep learning. :-)

--
Ytreq Q. Uiop