|
in reply to How to start. || Ramblings of a confused mind.
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.
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).
|
Re^2: How to start. || Ramblings of a confused mind.
by jkva (Chaplain) on Jun 09, 2005 at 01:03 UTC
|
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.
| [reply]
[d/l] |
|
|
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.
| [reply] |
|
|
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).
| [reply] |
|
|
There's certainly wisdom in that. I've noticed that indeed, when I use things, they stick in my brain more. In this logic it would be better to go for method two, it'd have the advantages of
- Necessary knowledge is gained
- Necessary knowledge sticks easier
If that takes less time than preparing by reading up for three days, then I should definately go for choice two.
Bah. It still makes me feel like walking into the camel desert of doom and realising after three days of walking that you forgot a lot of important stuff.
I probably just worry too much. Thanks for the advice.
| [reply]
[d/l] |
|
|
