Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Road map woes

by Limbic~Region (Chancellor)
on May 28, 2003 at 23:54 UTC ( #261441=perlmeditation: print w/replies, xml ) Need Help??

Brothers and Sisters,
I am just a couple weeks shy of having been at the Monastery 11 months, as well as discovering Perl. I never matriculated into college, so I do not have any knowledge of what classical "programming" is supposed to be. I am self taught in BASIC where I used goto as often as I could. That code could be described a spaghetti string at best. I literally used variables a-z and then started with a1 if I happened to use all 26. No indenting - well you get the picture.

I then dabbled in Pascal - and hated it. I learned enough C to write "hello, world" programs (really I got about as good as I was at BASIC), but thought the language was about as interesting as watching paint dry. I am not a professional programmer - I have never been paid for a single line of code. I solve problems - and sometimes I do that with code. So to this end, I have also written a lot of *nix shell scripts.

And then I found Perl. I am not going to get into how great the language is, or what the limitations are - this post isn't about that. I want to know how I can map my progress. The end goal after all is to realize that Perl is the game. I mentioned in the Chatter Box the other day that I have 13 books on Perl. The reasoning - I don't know what I need to know until I need to know.

I am familiar with the 7 stages and would rate myself barely a hacker. I found myself giving tutelage to another monk on references and closures and realized that I had assimilated this information without realizing it. I have grown in other areas and the point of this post is not to boast, but rather to find out what I don't know. Is there some checklist the Saints keep hidden away in one of the *hey - vroom is teleporting again* secret chambers? Some would argue that you only need to know enough to do the task at hand. I agree, but in my case I am not getting paid for this - I invent my own projects - so how do I challenge myself to learn something new?

Ok - I have become too verbose and think I may be babbling. I guess what I am saying is that I know what I know - how do I know what I don't know?

Cheers - L~R

Replies are listed 'Best First'.
Re: Road map woes
by Ovid (Cardinal) on May 29, 2003 at 00:14 UTC

    There are a few things you can do to keep advancing. The easiest is to pick up some good books about programming that aren't necessarily about a particular language. "Code Complete" and "The Pragmatic Programmer" are two excellent books for that.

    Another thing you can do is start learning different types of languages. Learning a more object oriented language like Ruby (or even Java) can do wonders for teaching what OO is really about and can help you better understand why Perl's OO is "bolted on the side". Learning a logic or functional language can also help you learn completely different ways of looking at problems. These will make you a better programmer in the long run.


    New address of my CGI Course.
    Silence is Evil (feel free to copy and distribute widely - note copyright text)

      Yes - this is good advice. I recently had the honor of assisting a fellow monk re-write 5 csh (c-shell) scripts that did a single function and took a LONG time to run. I discovered that my shell scripting had magically improved after being on a 6 month hiatus because of Perl.

      I will make an earnest effort at the book aproach as well. I do not want to use the excuse "I don't learn from books" or "I only use books as reference" since it isn't a real reason. Being realistic (as opposed to optimistic/pessimistic), I stick with a book until I am bored with it and then it becomes reference. I asked the question and if I am serious about doing it I should buckle down and try.

      Thanks - L~R

      I'd like to point out Split Scalars and Objects/References into Two Types which explains the "bolted on the side" remark -- it's not a bad read overall ;)

      MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
      I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
      ** The Third rule of perl club is a statement of fact: pod is sexy.

Re: Road map woes
by crenz (Priest) on May 29, 2003 at 01:19 UTC

    I know how you feel. Sometimes, there are posts at PerlMonks that exhibit an elegance that makes me feel there is a lot to learn still... but I don't know where to start.

    I like Ovid's proposal -- try to learn another language, it is really interesting. You could go for Java or C++, or for something more different: Prolog, ML, Lisp, Scheme. (I had these in school, and they helped me to think differently.)

    Some people like to occupy themselves with foundational CS books like "Structure and Interpretation of Computer Programs", but I find that I really learn best when tackling projects. (Nothing against the books -- I also use them in my studies, but I belief it might not be the right approach for L~R.) I know this advice has been given on PerlMonks a number of times, but I believe it is still true for your situation. You could choose a topic that really interests you and challenges you to learn something new, rather than applying concepts you already know in new ways. Some ideas:

    • Parrot. I'm serious, if you've never done Assembler, this should be real fun. You might even end up creating a few example scripts that help others.
    • GUI apps (ie., event-driven programming)
    • CS topics like linguistics, artificial intelligence, distributed systems, graphics/sound manipulation, bioinformatics. Choose something that interests you. You'll be surprised to see how much you can do even without formal Computer Science training if your curiosity guides you.

    Also, I would recommend participating in a larger open-source project. It is really quite different to do programming in a group, it would teach you a number of new skills.

    Note that I don't recommend specific skills that I belief you should learn about. First of all, I don't know your skillset, and second, once you are beyond a basic stage, you really need to pick the skills you want to learn yourself according to where you want to get to. E.g. if you plan to change your career to professional software development in the large some time, you will need different skills than if you plan to spend your future time teaching Perl or building web apps. So after you think about the possible directions that are open to you, pick a goal you want to be at in maybe a years time or two, and learn whatever skills you need to attain that goal.

Re: Road map woes
by djantzen (Priest) on May 29, 2003 at 01:59 UTC

    It may help first to think about what your goals are in a more general sense than directly about what specific bits of information you might want to assimilate. For example, you say that you're not a computer programmer professionally, but do you want to be? If so, one way to think about these issues is first to figure out generally what type of position you would be interested in applying for, and then pursuing and strengthening the requisite skills. For instance, the other day I composed a list of subjects that I'd be less than comfortable discussing in an interview, and so built myself a syllabus of material and a rough timeframe for e.g., basic XML proficiency, review of certain algorithms and O(N) notation, C/C++ review, etc.

    If you're not planning to pursue software as a career, perhaps you'd be better off just thinking about the kinds of problems you like to solve. A diligiently curious person -- as you seem to be -- will find it very difficult to exhaust the realm of digital possibilities, so follow your muse.

    I think it makes more sense to begin from a more abstract, goal-oriented perspective than to take something like "the 7 stages" too seriously, as the latter assumes that the reader is actually interested in learning the minutia of every aspect of Perl coding. Its ranking doesn't take into account the interests or professional emphasis of the programmer in question. I find that I fit no stage well, but only a vertical sampling from nearly every one.

    "The dead do not recognize context" -- Kai, Lexx
Re: Road map woes
by markjugg (Curate) on May 29, 2003 at 02:48 UTC
    Look out for those moments where you find yourself thinking "There's got to be a better way", whether you have in a mind a 5 second task or an application architecture. There is a probably a better way. And chances, at this point, someone has probably already figured it out and published it somewhere.

    This at least feels like a primary way that I improve. I start with the sense that there is a better to approach a particular problem, and I start to research and discuss that.

    Some things took a lot longer to figure out and sink in. Reading "Code Complete", as mentioned above, has really helped with my understanding of appropriate use of global data. In retrospect, I would have read more books on the theory of programming earlier on. It's easy enough to find a helpful module on CPAN for a particular task. It's harder to find a good resource that discusses the merits of one software design philosophy versus another in a useful way.

    Perlmonks is useful, but you aren't likely to get a 15 page response examing the details on how to best name subroutines. :)


Re: Road map woes
by perrin (Chancellor) on May 29, 2003 at 15:12 UTC
    The most effective way to improve your programming skills is to get a job working with people who are better at it than you are. It worked great for me.
      So very true. While I was working at a company that had at least one programmer/designer/etc that was lots better than me, I got better every single day, and often not by little either.

      The, on the other hand, I spent over a year at a company where I was by far the best programmer (and probably one of the best computer guys all categories). Not to be taken as that I'm very good. Only compared to those others. It was pure pain most of the time. While it felt good to be able to solve problems for the others, and getting lots of credit and respect, I hardly evolved at all, more likely I lost some skills. The credit doesn't matter all that much when you really don't have to work hard at solving the problems at hand. There were a few times I needed to think hard, but oftenly it was pretty easy stuff.

      Furthermore, disliking my situation at that job so much made me lose the interest in doing fun stuff for myself at home as well, becoming quite apathetic for a while. Thank goodness I'm not working there anymore. I'm starting to feel my old self again. :)

      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.
        Dog and Pony,
        Thank you so very much. I recently gave my notice at a place where I was in the same perverbial boat as you. I have found the majority of my jobs as not satiating because of this very reason. I know that I am not that good - I find myself in the presence of greatness everytime I log into PerlMonks. I guess I will start looking for a job where I am the least qualified (figuratively speaking) and not the most qualified. Thanks again for putting some perspective on this problem for me.

        Cheers - L~R

Re: Road map woes
by nimdokk (Vicar) on May 29, 2003 at 13:09 UTC
    I might recommend a course (or book) on Logic. I took one course in that many years ago and that has helped immensly with my programming skills, such as they are. Might help, might merely be redundant as well :-)

    "Ex libris un peut de tout"

Re: Road map woes
by Anonymous Monk on May 29, 2003 at 18:50 UTC
    Read about Comp Sci Theory. Read about common algorithms. Knuth++
Re: Road map woes
by msemtd (Scribe) on May 30, 2003 at 19:16 UTC
    Hi L~R,

    Firstly, I have to admit that I have only skimmed the replies thus far but I truly have ready your question!

    My answer to the question is... If you have read the camel book and understood it then you know the language. The camel book is IMHO the definitive description of the language. If you wish to go further or deeper, Advanced Perl Programming (the puma book?) is recommended. Furthermore, we are all in the situation of not knowing what we don't know (in detail anyways!) so if you come across something you didn't know and then come to know it, then you know you are truly making progress on the randomly meandering path to an unknown goal.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://261441]
Approved by ChemBoy
Front-paged by herveus
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (4)
As of 2021-01-27 07:28 GMT
Find Nodes?
    Voting Booth?