Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

the next step

by emilford (Friar)
on May 09, 2002 at 06:27 UTC ( #165265=perlmeditation: print w/ replies, xml ) Need Help??

Hello Monks,

I've been programming Perl for roughly a year, but have programming experience in several other languages. I started teaching myself Perl (along with PHP) as a result of an internship position that required generation of dynamic webpages.

Since then, I've stuck with Perl and have used it for a wide range of things, ranging in levels of difficulty. I love programming in Perl! I buy books to learn more and hang out at PM.org to learn from others with more experience. After a year, I feel my knowledge of Perl is strong enough to get things accomplished, but I often find myself providing a drawn-out response to a question that other Monks answer in a few lines of usually fairly complex code.

Perhaps my problem is not enough "real world" experience. While others program in Perl for a living, I spend my Perl time building personal webpages and tossing together a few reg exps to manipulate parts of a document. I'm looking to obtain a job as a programmer after I graduate college, but feel that if I'm going to have ANY chance of making it as a Perl programmer, I need to get on the ball.

I guess my question is what I should do to take my knowledge of Perl to the next level. I own several Perl books and have read through them, but I don't feel like my ability to program efficiently in Perl is increasing. What should I do? Pick up more books? Look through professional level code? What is the normal next step (if there is one) for an aspiring Perl Monk? I feel like I've hit a brick wall, but know that there is certainly MUUUUUUUCH more out there for me to learn. Is there a direction that I should head in (webpages, databases, etc)? What's hot on the market?

Okay, excuse any "unclearness" in this post, but I'm exhausted from a week of final exams. Oh boy, Operating Systems final exam tomorrow, bright and early!

Thanks in advance. -Eric

Comment on the next step
Re: the next step
by Biker (Priest) on May 09, 2002 at 06:46 UTC

    Decide upon a product and create your own development project. Look around of what already exists. Decide to do something that noone has done (well) so far. Then start your own development.

    It doesn't really matter if you go database, CGI, a combination thereof or any other direction. What is important is that it's a direction you will appreciate (or it won't be finished) and preferably that it's something new (or at least very much improved upon).

    What software would you like to have? What do you miss in your software setup?

    Once you have an idea and you start working on it you may feel that you want to involve other people. Or not. Your call. It all depends on the size of the project and your commitment.

    Benefits:

    • You will learn a lot in a project that is interesting to you. (Which is not always the case when working as a professional developer.)
    • You can sell yourself on the professional market with your own project in your CV.
    • You can (hopefully ;-) be very proud of your product.

    Everything went worng, just as foreseen.

      Decide upon a product and create your own development project. Look around of what already exists. Decide to do something that noone has done (well) so far. Then start your own development.

      I have to disagree.

      If there's a project you want to do, and you want to start from scratch -- then by all means, that's your perogotive. But in the case of this poster the goal is to learn more perl, and to become more marketable with perl skills.

      There are already lots of perl projects out there that you can contribute to. Working on an existing project can have all of the benefits Biker described (something that intrests you, something you can point at when you sell yourself, something you can be proud of) and it has the added benefits of letting you see other peoples code, and helping you learn how to work colabratively with other people on software (things most people don't learn working on small scripts, which are frequently more marketable then just knowing a lot about perl)

        And I'll disagree with both of you ;-)

        Biker sez:

        Look around of what already exists. Decide to do something that noone has done (well) so far.

        For a first-time project, I wouldn't recommend trying to beat out everyone and design something completely original. You'll waste a lot of your time coming up with the idea, and the point was to learn Perl better, not to sit around trying to figure out a great idea for a project.

        So just pick something you think you can learn from. Who cares if you're reinventing a wheel? You're learning. Yes, there are some things the open source community needs more of (and many it needs less of ;) but those should be reserved for the second project.

        hossman said:

        There are already lots of perl projects out there that you can contribute to. Working on an existing project can have all of the benefits Biker described

        For those who haven't been involved in any open source development before, it would be better to start their own project from scratch. This would allow them to do all the design themselves, which is at least as important as writing the actual code. They won't miss out on colaborative development this way either if their project can attract other developers.

        As for marketability, starting an open source project probably looks better on your resume to most employers than contributing to one. It also helps you develop language-independent design skills, which is a good thing.

        To reduce the number of flames I should note that yes, as a side effect if everyone followed my suggestions the noise/signal ratio of open source projects would increase. It is however usually pretty easy to discern the quality of a project, and when you consider that this means more people are learning through open source development, I don't think it's much of a problem.

        Update: Here's a couple of relevant HOWTO docs you might want to take a look at:

        Best of luck :).

Re: the next step
by cjf (Parson) on May 09, 2002 at 07:48 UTC
    but I often find myself providing a drawn-out response to a question that other Monks answer in a few lines of usually fairly complex code.

    First of all, drawn-out responses are often far easier to learn from than quick one-liners. Secondly, other than to figure out faster ways of learning, I wouldn't focus on the time, or amount of typing it takes to learn something. See The Path to Mastery for more on that idea.

    What should I do? Pick up more books? Look through professional level code? What is the normal next step

    Reading books and other's code are decent ways of learning, but I've found that starting a project is far more effective. Consider some of the ideas in Where the inspiration comes from ? and you should be on your way. :)

Re: the next step
by kappa (Chaplain) on May 09, 2002 at 07:53 UTC
    Hm, first of all, don't panic :) One year is not usually enough to become a wizard, as you probably know. Just keep having fun with Perl and don't worry, you'll get where you want!
Advancement by scratching...
by pdcawley (Hermit) on May 09, 2002 at 10:38 UTC
    It's something of a truism that most of the great software that exists does so because the programmer had an itch he wanted to scratch. (This probably explains why a good programmers' editor is so much more satisfying to use than a word processor, the people who use the programmers' editor are the people who program it. If there's something that bugs them about the app, they fix it and move on.)

    It seems to me that, if you really want to get better at your craft you should find something that you need and implement it. Assuming you have the time, implement it yourself. Then go out and see if someone else has done it. If they have, compare your wheel with theirs and work out why theirs is better (or worse) than the one you made.

    Then find another itch and do it again. Rinse, lather and repeat. If you don't get better at your craft in this process I'll be amazed.

    Of course, reading around the subject couldn't hurt either. Grab one of the classic computer science/engineering texts and read that. Read up on (and play with) a few languages that do things differently from what you're used to. See how those ideas map to perl (and vice versa).

    Because you'll always be working on stuff that is useful to you, or that you find interesting, you'll be able to track your improvements. If you're working on something because it's popular, or because it seemed like a good idea at the time, chances are you won't really engage with what you're doing and you won't really gain much from the experience.

Re: the next step
by Sifmole (Chaplain) on May 09, 2002 at 11:17 UTC
    I guess my question is what I should do to take my knowledge of Perl to the next level

    Is your goal really to just take your Perl skills to the next level? If so, then make sure you read all the O'Reilly books ( Programming Perl, Advanced Perl Programming, The Perl Cookbook, etc. ), read the Manning book on Object Oriented Perl, read professional Perl, read the most popular Perl from CPAN.

    However, I personally think programmers who focus too much on one language become like a carpenter with only a hammer; Of course Perl is one extremely versitile hammer...

    You are apparently studying either Comp Sci or Info Sys; My personal suggestion is to learn more about the art/craft/science of Software engineering. Everything you learn there will be applicable to employment, and will make your Perl skills stronger.

    And while I am sure others are Gurus in the amount of time I have been programming Perl, seven years, I still find something to learn about Perl all the time; So enjoy the ride and just keep writing.

Re: the next step
by adamcrussell (Hermit) on May 09, 2002 at 13:40 UTC
    First, let me address the question of "What is hot on the market?" given the context of the rest of your post(getting a position of some sort that will allow you to grow as a perl programmer). The biggest single industry which has a use for perl programmers is biotech, specifically bioinformatics. I may be biased because that is the field in which I work. Of course, many industries have a need for perl programmers, some of which may not even know until you show them!! >:)
    My advice to you is to get any job that you are reasonably satisfied with so that you can at least ay the bills and get the real world experience necessary to move your career forward.
    Oh, and although many others in this thread have mentioned open source development I think your original post dealt specifically with paying gigs, right? In that regard I have never *ever* had an interview where the person interviewing me asked or cared about experience gained outside of paid employment(i.e. school and open source projects). Just my mileage, others may vary.
      I'm glad to hear that bioinformatics is hot on the market, seeing how that field is one of my primary interests. Bioinformatics is also the field I have the least experience in. If I were interested in pursuing Perl in this direction, what recommendations could you give me? Are employers looking for people with strong Perl backgrounds or stronger science backgrounds? Is it possible to get a job doing bioinformatics with a solid understanding of Perl, but only a basic science background?

      I can see your point of view that open source isn't always what companies are looking for, but what other ways do I have to get "practical" experience. There is a sick cycle of you need the job to get experience, but you need the experience to get the job. Many struggle with getting into that circle in order to get that initial experience. Companies tend to want programmers with 5+ years experience in a specific field. How am I suppose to get that experience if a company is reluctant to hire me?
        I guess it depends on the employer. Most places put a big emphasis on the science though. Many pure "science" types think that they can get a biologist and have them learn programming but that a Comp. Sci. type is somehow incapable of learning the science in order to effectively translate the solutions to problems into code. My best advice is to get some experience as a paid employee with a university lab group. These are the spots which are most likely to hire a programmer and let them grow. Of course, look into as many opportunities as possible, it is just that places like that have a lower barrier to entry.
      Two other fields that use perl a lot: Testing and Quality Assurance. Lots of large test engines for software packages are written in Perl. This is doubly true if your software has to be tested on many platforms. You might look at getting an Internship in a testing department (make sure your not just clicking buttons). It could work out well that you get to write code, and learn first hand from people who know their stuff.
      -my 0.02
Re: the next step
by FoxtrotUniform (Prior) on May 09, 2002 at 15:59 UTC
      I guess my question is what I should do to take my knowledge of Perl to the next level.

    One way to raise your expertise: expose yourself to different languages, see what they do well, learn their idioms, and apply that to Perl. Lisp is the best example I can think of: if you get into Lisp, you'll learn all kinds of cool tricks involving anonymous subs, closures, lists, function application, and functional programming. (You can get pretty much the same techniques out of Haskell, but you'll miss currying and you'll even get to keep currying when you switch back to Perl.) Most of these tricks can be done in Perl.

    As a happy consequence, you'll also have a bigger toolchest of techniques to use. Some problems are hard with one tool, and trivial with another.

    Another way, which works really well and shows results quickly, is to subject your code to relentless peer review. Having other people paw through your work, pointing out which bits are awkward, which are error-prone, which are hard to maintain, and sometimes which are elegant, is a tremendously valuable learning tool. If learning other languages expands your toolchest, code review sharpens the tools.

    I can't emphasize enough how important code review is. I'd say the primary advantage to working on an existing Open Source project is that you'll be able to push your code on other experienced programmers for review.

    As a happy consequence, you'll develop some extra humility.

    Update: Clarified the Haskell/currying point: you'll miss Haskell's currying when you go back to Perl. (IIRC, Perl 6 will support curried functions, so maybe it's not so big a deal.)

    Update 2: So you can get curried functions in Perl, albiet with a bit more trouble than in Haskell. Thanks, educated_foo!

    Good luck.

    --
    :wq

      You can get pretty much the same techniques out of Haskell, but you'll miss currying.

      Huh? Haskell's curried...

      foo a b c = a ++ c ++ b with_parens a b = foo a b y = with_parens "<" ">"
      then print (y "banana") prints "<banana>". BTW, if you haven't, you should definitely check out Haskell, as it can be a truly mind-bending experience. It's easy to get up and running with the HUGS interpreter, now with delicious readline support.

      /s

      Update: you won't miss the currying anymore...

      use strict; use Carp; use Attribute::Handlers; sub _curry { my ($n, $func, @args) = @_; return sub { my $narg = @args + @_; if ($narg > $n) { carp "$narg args to curried function (expects $n)."; } elsif ($narg < $n) { return _curry($n, $func, @args, @_); } else { return &$func(@args, @_); } }; } sub curry : ATTR(CODE) { my ($package, $symbol, $code, $name, $n) = @_; confess "Usage: sub mysub : curry(N), where N > 0" unless $n; local($^W) = 0; no strict 'refs'; my $newsub = _curry($n, $code); *{$package . '::' . *{$symbol}{NAME}} = $newsub; } sub foo :curry(3) { print "foo: @_\n"; } my $x = foo(1,2); &$x(3); &$x(2);
      Yeah, I was a bit confused by your Haskell and currying comment. Would you like to elaborate that one for my boggled mind. :P

      On the other hand, I 100% agree with your comment on getting your code reviewed. There is no better way than to learn from your mistakes and the experience of others. It's almost like having a mentor who can guide you along the path to Perl Wisdom. I'm not too sure, however, just how willing people will be to critique my code in the Open Source world. I'm sure they're more looking for programmers to get the job done quickly and efficiently.

      I guess the only way to find out is to jump right in!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://165265]
Approved by cjf
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (9)
As of 2014-11-26 20:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (173 votes), past polls