in reply to Reading the manual and knowing if you are getting good

How often a day do you/would you expect to be doing a perldoc?

At least once a day, often more. It depends on what I'm doing that day. Sometimes it's a matter of using a module or function that I haven't used much; other times, because so many functions and modules are so "nuanced", with many subtle variations on their basic operations, it's a matter of learning to do more with tools I already know about. (Then, with things like pack/unpack, I just have to look it up every time, no matter what.)

Can this be a measure of how good your skills are becoming?

If you're able to locate, absorb and apply the knowledge provided in perldoc man pages, this by itself indicates that your skills are "above average", IMHO.

I am starting to see things now (answers to the problems that is ;-) ), but only in bits and peices. Can you just see things?

This is only partly a matter of being skilled with a given programming language or knowing how to read man pages. I think the larger part is a matter of being able to analyze a problem or goal, to understand the nature of the inputs and the required properties for the outputs, to picture the solution as a particular set of objects and/or data structures and/or procedures -- and crucially, to be able to describe the solution in reasonable detail before starting to write code.

If you're on CPAN you are good?

If you've posted code to CPAN, it means that you have figured out how to post code to CPAN, but it doesn't necessarily mean that you've written good code or that you can be counted on to consistently produce effective solutions. And of course, I'm sure there are many highly competent programmers who have never posted anything to CPAN.

When did you start to notice that you were getting good?

Funny question, tough to answer. I think it may be nearly impossible to guage the accuracy of self-appraisal (I can recommend an old thread on this topic: On Hubris.) A more pertinent question might be: "When did you start creating solutions that were completed sooner, performed better, and/or solved more problems than you or others originally expected?"

I've been having that experience repeatedly when doing a wide variety of one-off scripts with perl: I need to create some particular output from some given input, I figure out what sort of data structure and process will accomplish this, I start writing the script, and at the point where I write the output loop and it's ready to run, I'm struck by how short the script is, and how little time was needed to write it.

  • Comment on Re: Reading the manual and knowing if you are getting good

Replies are listed 'Best First'.
Re^2: Reading the manual and knowing if you are getting good
by Anonymous Monk on May 31, 2005 at 21:41 UTC
    "When did you start creating solutions that were completed sooner, performed better, and/or solved more problems than you or others originally expected?"

    This question implies that poor resource estimation skills are a sign of a good programmer. I contest that suggestion.

    If you finished sooner than you expected, what was wrong with your original timeline estimate? If you "performed better" than expected, why did you underestimate performance in the first place? If you "solved more problems" than expected, why didn't you correctly explore the problem space to begin with?

    Learning the answers to these questions, each time you don't do exactly what you expected, is important as well. Learn to do exactly what you set out to do, with the resources you intended to do, exactly as planned. If you can't, work on your design skills, or your planning skills until you can.

    When you do exactly what you intend to, with the resources intended, and the product works exactly as designed, then you've got a solid development process. When you can do that, then working out what you want to accomplish is all that's left; it's a hard job, too, but easier than most of the others.

    --
    Ytrew