Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Reading the manual and knowing if you are getting good

by ghenry (Vicar)
on May 30, 2005 at 21:26 UTC ( #461868=perlmeditation: print w/ replies, xml ) Need Help??

Dear Master Monks,

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

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

I remember my Electronics Engineering lecturer saying to my class once:

"You know when you are getting good, when you just see things"

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

Can you just see things?

I also appreciate that a person can never stop learning, but surely, if you're on CPAN, you must be getting good.

Is that it then? If you're on CPAN you are good?

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

Please step up and be honest, I know there's lots of excellent programmers on here ;-)

Gavin.

UPDATE: I like the way graff re-worded one of my questions, so I am asking it here:

When did you start creating solutions that were completed sooner, performed better, and/or solved more problems than you or others originally expected?

Walking the road to enlightenment... I found a penguin and a camel on the way.....
Fancy a yourname@perl.me.uk? Just ask!!!

Comment on Reading the manual and knowing if you are getting good
Download Code
Re: Reading the manual and knowing if you are getting good
by itub (Priest) on May 30, 2005 at 22:37 UTC
    I think not reading the manual doesn't necessarily mean that you are good, but that you are very familiar with what you are using (which might be a very small subset of Perl!). And even if you are a Perl super-guru, if you are using an unfamiliar module (and no one can be familiar with all of them!) you'll have to look up the documentation.
Re: Reading the manual and knowing if you are getting good
by brian_d_foy (Abbot) on May 30, 2005 at 23:24 UTC

    I've been teaching Perl for years, and I still use perldoc every day that I use Perl (and not just for module docs ;). Even though I teach and write about Perl, I don't use every bit of it every day and I forget things. Some things I can't keep straight, such as the order of things in stat() or localtime(), and some things I always check to ensure that its supposed to do what I think I'm doing during those debugging sessions where I start to wonder if someone has changed the universe on me.

    I have a lot of modules on CPAN, but that doesn't mean that they are any good, and it doesn't mean that I am any good. My modules are always getting better (like I mention in Parallel maintenance on many projects, part I and Parallel maintenance on many projects, part II: The Testing). Some have sucky names, like I mention in Regrettable module names.

    For me, knowing that I am getting better involves thinking about why I know what I know (How I learned Perl) and why I do the things I do (How do you master Perl?, How not to code). Sometimes that means being self-critical, like in Stupid mistakes I repeatedly make. Indeed, search for "dumbass" on Use Perl and you find posts where I use that on myself.

    I don't know if I can "just see things", but things that seemed hard four years ago seem easy today. That's got to be worth something.

    --
    brian d foy <brian@stonehenge.com>
Re: Reading the manual and knowing if you are getting good
by Tanktalus (Canon) on May 30, 2005 at 23:28 UTC

    I don't even see the code. All I see is...blonde, brunette, red-head...

      Woah.

      Well, someone had to say it . . .

      --
      We're looking for people in ATL

Re: Reading the manual and knowing if you are getting good
by graff (Chancellor) on May 30, 2005 at 23:48 UTC
    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.

      "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

Re: Reading the manual and knowing if you are getting good
by tilly (Archbishop) on May 31, 2005 at 02:36 UTC
    If you think that you're getting good, then your standards need readjustment. I've long noticed that truly good people tend to be aware of how they could improve. (Else they would have long ago stopped improving...)

    UPDATE: At least one person's private response suggests that people think this node was meant to be insulting. That is not so. I'm commenting on the phenomena that becoming proud of how good you are is a quick way to ensure that you get no better. See What you refuse to see, is your worst trap for a longer essay of mine on that general theme.

Re: Reading the manual and knowing if you are getting good
by zentara (Archbishop) on May 31, 2005 at 10:28 UTC
    "You know when you are getting good, when you just see things"

    Thats probably true, but the perldocs are for "getting the details right". When I look at a problem, and "see" the answer, it is almost always "pseudo code". You know, throw that into a hash, regex that, and presto "script magic". BUT the actual working implementation, involving the real details of a working-error-warning-free script, requires looking at the perldocs quite often. This is especially true if you know more than one language...you can't memorize all the different syntax for different languages, and not get them mixed up.....you need reference guides...the perldocs.


    I'm not really a human, but I play one on earth. flash japh
Re: Reading the manual and knowing if you are getting good
by dragonchild (Archbishop) on May 31, 2005 at 12:52 UTC
    Memorizing perldoc shows you can memorize stuff. I prefer to have a general grasp of perldoc, so that I know what's out there and where to find the details. perldoc exists so that I don't have to remember what's in perldoc.

    IMHO, becoming a good Perl programmer is more about becoming good at programming than at Perl. If I was hiring someone into a senior position, I would be looking for the following (in no particular order):

    • Do you write tests?
    • Do you use SCM? Do you have opinions on which SCM to use?
    • Do you code in such a way that you have to think about less things at one time?
    • Do you enjoy code reviews?
    • Do you look for requirements and design reviews?
    • Do you have an opinion on source code structure?
    • Can you solve any given programming task in at least two completely different ways?
    • Do you have an OSS distribution (in any language hosted anywhere)?
    • Are you willing to argue your point in the face of everyone else? Can you do so without cussing?

    As I answered "Yes" to more of those questions, I realized I was improving as a programmer. As I add to that list, I know I'm learning more about what a good programmer is.


    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
Re: Reading the manual and knowing if you are getting good
by jeffa (Chancellor) on May 31, 2005 at 13:35 UTC

    Greetings ghenry. I am going to attempt to answer your overall question by talking about something else. Drums. I have been playing drums for about 17 years now. When i started, i was good ... for newbie. I was quite good actually, but i was still a newbie. I couldn't hold my weight in a band, but i had the aptitude (and passion) to learn more, to be better. As the years rolled on and my practice continued, i got better. And better. And better. I was still good -- but i was not, am still not, and perhaps will never be ... GREAT.

    You see, it really is not about the destination. It's about the journey. Being good means nothing without prefacing where you are on your timeline. We all have different levels of attainment. You can be really good at getting stuff done -- but don't nobody look under that hood. ;) You can be really good at building that engine under the hood, clean and efficient -- but don't deliver on time and tend to "overkill."

    In short, you know how good you are by judging yourself against your peers. And if you really want to be good, if you really always want to aim for greatness even if you will always fall short ... surround yourself with those better than yourself.

    Hope this helps. :)

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    

      ... surround yourself with those better than yourself.

      That's exactly why I hang out here. This place is swarming with programmers that are better than me. I'd be amazed if if the day ever came when I could lurk in SOPW and not learn a tidbit or two!


      Spem Successus Alit
Re: Reading the manual and knowing if you are getting good
by tlm (Prior) on Jun 01, 2005 at 04:06 UTC

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

    I wouldn't put it that way, because it implies that there is a clear boundary dividing the before and after "getting good." I don't think it's like that; there's always stuff to learn, and there's always stuff to get better at.

    I look at Perl code that I wrote 1, 2, 5 years ago, for example, and I definitely see a pattern of improvement, but I can't point to a watershed moment after which my programming "got good".

    BTW, I read the docs all the time. I doubt I'll ever know Perl well enough to be able to make do without reading the docs this often.

    the lowliest monk

Re: Reading the manual and knowing if you are getting good
by toma (Vicar) on Jun 01, 2005 at 07:15 UTC
    Is your EE lecturer's quote "You know when you are getting good, when you just see things" about circuits?

    There comes a point in understanding circuits where you can look at a schematic and read the intent of the design, and understand its operation. Although the diagram may show an ocean of resistors, capacitors, inductors, transistors, transformers, connectors, etc, you get to the point where you just see the flow and understand the circuit (if it is well-drawn).

    Many flaws in circuit design can be spotted by inspection. Your eyes are drawn to problem areas, where things just don't look right. This is not a brute-force calculation. It is similar to chess, where a master sees only a few moves where there are opportunities. This is in contrast to a computer, which plays chess by evaluating myriads of moves.

    When you get really advanced, you can even see humor in some schematics, both in the way the diagrams are drawn, the choice of components, and the topology. When someone points and laughs at your schematic, it is not unlike the experience of someone pointing and laughing at your code.

    In many ways reading code is harder than writing it. You are good when you can read someone else's code, appreciate what is good about it, and see where it is likely to have problems. This can be done quite quickly and intuitively.

    I am much better at reading schematics than reading perl code! There are many great books that help you learn to read code, though. For help reading schematics, the titles are far fewer. 'The Art of Electronics' by Horowitz and Hill is the title that comes to mind for circuits.

    Like a well-coded test suite, a very thorough simulation of an electronic design can result in detailed analysis of design flaws. I have found that these thorough simulations must be created by someone who understands the circuit. In other words, black box simulation does not work for the types of analog designs that I look at. This leads me to suspect that software test development is also not best when it designed on a black-box.

    The analogies between hardware and software run deep.

    It should work perfectly the first time! - toma

      Yes it was.

      I also have that book. He was the best lecturer I ever had.

      He worked for Hughes at 20 and helped design the propulsion systems for the Firebird/Firefox aircraft. He also helped develop the first ever Virtual Reality System for the Military and now works on Propulsion systems for space crafts, I think.

      Walking the road to enlightenment... I found a penguin and a camel on the way.....
      Fancy a yourname@perl.me.uk? Just ask!!!
      This leads me to suspect that software test development is also not best when it designed on a black-box.

      Amen to that.

      Years ago I was responsible for defining the test plan for an OS/2 replacement for a previos DOS app. I was given the IT department generated (black-box mandated) test plan for the original as a starting point. It consisted of a stack of green&white lined fanfold about 7 inches thick. The first 1 1/2" of that were the tests for checking the handling of the applications configuration file.

      Of the 20-something lines in the file, 14 were fully qualified path names to various other files. For each of these there was a comprehensive set of tests that consisted of manually editing the line of the config file to introduce particular errors (non-existant drive letter; non-existant directory; space in a directory name; space in a filename; non-existant file; etc. etc.) and then running the program and ensuring that it detected the errors. This batch of tests (the first 1 1/2") took 2 people a week to run.

      Looking inside the code, it was obvious that

    • If the errors were detected in one of the 14 lines, they would be discovered in all of them.
    • The program simply passes the path as read from the config file to the CRT open() and reported back whatever errors it found.

      Given that the waterfall development method required that these tests be re-run every time the program was modified--even if the change was a totally trivial spelling correction; or something major but in a completely unrelated part of the program--the cost of that "black box innocence" to the reality of the inner workings was huge over the 7 years and hundreds of versions that had been tested.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2014-09-02 05:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (20 votes), past polls