Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

I Don't Know What I Need To Know

by nimdokk (Vicar)
on Jun 05, 2003 at 18:31 UTC ( #263447=perlmeditation: print w/ replies, xml ) Need Help??

It has struck me upon occasion (most recently as I was reading Amel's tutorial Lexical vs. Package Variables ) that frequently when I am learning something for the first time (be it Perl or kayaking), it is often difficult to come up with the appropriate questions to ask to learn more about whatever it happens to be at the time. I think that this is so simply because at the outset, my frame of reference is simply too limited to fully understand all (or even enough of) the ramifications to know what to ask.

For instance, several years ago, I started work as a third-shift computer operator at a hospital. I had about 2 weeks of training from the operator whom I was replacing (so he could switch to first-shift). There was quite a bit of information to absorb in a short period of time. At the end, he asked me if I had any questions but at that point, I was simply too inexperienced with the nuances of the job to be able to frame appropriate questions. Questions that did not occur until I had actually been doing the job on my own for a while. The old adage "practice makes perfect" rings true but we also have to consider that we are never perfect, so we are always practicing to improve our skills (whether those are programming, kayaking or whatever).

Someone mentioned in the ChatterBox the other day about looking back at code s/he had written 6 months before and thinking about how poorly it was written. Then in another 6 months, looking at code that s/he was currently writting and thinking the same things. Learning is evolutionary, we are always learning new and (hopefully) better ways of doing things.

So, how would you know what to ask when you don't have the appropriate background with which to frame a question? On the one hand, when dealing with specifics, you can't. However, by being able to make connections and tieing in the currently available information to that which you might already possess, it is possible to ask leading questions so that you can get the proper background with which to ask questions that can lead to further enlightenment. Sometimes though you simply have to let things fester in your skull for a while and play around with it in order to get a better understanding of the in's and out's before going back to sit at the master's feet for more lessons. Since our frame of reference is always changing, we need to constantly ask new questions. As teachers in school frequently said: the only stupid question is the one not asked. We can't be expected to learn everything at once and so are constantly growing in how we do things (this can apply to things outside of coding/programming as well). The Japanese have a neat little phrase for this: o-negai shimasu. Which means, loosely translated, "please teach me."

So, what is an answer to the little dilemma posed above? Practice and patience. Of course, as with many things, "There is more than one way to do it" and there are more possible answers than there are stars in the heavens above. :-)

"Ex libris un peut de tout"

Comment on I Don't Know What I Need To Know
Re: I Don't Know What I Need To Know
by Juerd (Abbot) on Jun 05, 2003 at 20:38 UTC

    Does your post have the right title? It is "I Don't Know What I Need To Know" but I think your problem is better described as "I Don't Know What I Need To Ask".

    And if your question is indeed "What do I need to ask?", the answer is very simple: ask what you want to know and cannot find out yourself. It is probably bad to look for questions to ask, since that would disallow you to concentrate on the real learning.

    Asking questions is of course a good learning method, but in my opinion, only if you ask questions that arise spontaneously or while using the language. If you find yourself wanting to ask questions but unable to think of one, you should probably not ask at all, but instead read a book (and existing code).

    The answer to the question "What do I need to know?" is even simpler: you need to know whatever is enough to accomplish what you wish (or need) to accomplish. If you don't know your goal, just read books, documentation and sources. If you do know what you want to do, I assume you also know the right questions to ask :)

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      You're right, it probably should have been titled "How do I know what to ask?" I was feeling somewhat philosophical this morning when I started writing this :-)

      "Ex libris un peut de tout"

Re: I Don't Know What I Need To Know
by svsingh (Priest) on Jun 05, 2003 at 20:44 UTC
    Well said. Honstly, most things I've learned, I've learned from watching others. Especially when it comes to computers. So much of what I know how to do in UNIX came from asking a developer a question and then watching them navigate at the command prompt as they tried to find the answer to my question. From that I learned find, using Tab for filename completion, and even got into a bit of shell scripting.

    That doesn't really answer your question of how do you ask what you need to do to do the task at hand, but I've found few things in life that are totally independent. The trick you learn today just becomes a part of your experience and will probably end up being useful in a way two years from now that you never thought of.

    For the immediate learning, I just carry around lots of notepads. When trainers ask if I have any questions, I just say I'll get back to them in a week or so. Whenever I have a question, I write it in the book, and then after a week, I'll see what I can answer myself. What's left goes back to the person who offered to answer any questions.

    Basically: watch and learn, live and learn. Hope this helps.

Re: I Don't Know What I Need To Know
by Necos (Friar) on Jun 05, 2003 at 22:20 UTC
    I personally think that when you are learning something new, you should be trying to take everything apart. If you're learning about references, you should be asking about _WHY_ they're there, _WHEN_ to use them, and _WHAT_ are the advantages of using them. Then you could ask about the internal implementation, but you probably won't ask that for a while. It's usually a bad idea to try to learn everything in one swoop.

    To be more general, when you are learning something, there are usually a lot of questions that come to mind, but you're either scared to ask them (because they may sound stupid) or you're dismissing them because you're trying to absorb the newer information coming in (of course there are other reasons, but I think these are the most prominent). To me, the more confidence you have in asking questions, the more likely you are to ask more as time goes by (duh, right?). Children are probably the best example with the: "What's this?" or "Why's that thing there?" type questions.

    On the other hand, I'm in a similar situation. I've been studying C for some time. I know most of the basics, but now, I'm thinking to myself: "what next?" I know there's more to C than just the basics found in the introductory books. There's socket programming, building your own header files, building your own libraries (which is tied to header files), etc. There are a bunch of resources online that will teach you some of the more advanced C topics, but there are so many that sometimes finding a few good resources is like the proverbial "needle in the haystack." So, I think there's more to your question than "I don't know what to ask to learn what I need to know." There's also a need to find out what information has more immediate use to you, so that you can learn other things. You wouldn't try to understand objects before you understood all of the variable syntax in Perl (well, I hope not ^_~). You wouldn't try working on a car without any previous knowledge. Both examples require some prerequisite knowledge. Trying being as inquisitive as a child. I bet you'll learn a great deal.

    Theodore Charles III
    Network Administrator
    Los Angeles Senior High
    email->secon_kun@hotmail.com
    perl -e "map{print++$_}split//,Mdbnr;"
      Here, here.. Too bad I can only upvote once ;)

      In computing in general, and even more so in coding, people tend to get blinded by complexity, and forget that everything is based on a simpler building block.

      Case in point when writing code there are only a handful of different actions that can be done. Declarations/Assignments, Testing structures, and Looping structures. From there you can get into the particulars of each of the items. Then view variations between say perl, python, java, C, C++, the benefits and drawbacks of each implementation. A slightly more concrete example would be routing protocols. Once you grok the OSI layers, what type of transport mechanism youu have, etc... it can become trivial to pull apart a brand spanking new implementation of say BGP or something. Due to the basic foundation in networking, you can pierce through the complexity that looks to "outsiders" as something revolutionary.

      A response to the OP would be that my code constantly morphs in style, though its directly proportional to the effort spent doing something in a given period of time. I.e If I'm not using it I'm not growing in said field. Sometimes I find immense pleasure in the fact that I see so many things I know I don't know, and the projections I can attempt to make for things I don't know I don't know. For me computing is so rich, which is good as I tend to get "bored" with shallow topics. Other times the same projection weighs on me so heavily that I almost consider doing something else. *almost* ;) ... The thought is something to the effect of "Man, will I ever finally grok this?" or "I just wish I could get ahead of this damnable learning curve". Personally as long as I keep my focus on what I know I don't know, I know that I will continue to grow.

      I have found the best way for me to learn is to attempt to find a basic level, whether some topics need to be deferred till later, and then begin assimilating the present information. Once you understand the "why"s of things, the hows et all, become in most cases intuitive extensions. Also this allows for me at least to be able to identify possible problems or enhancements in a relativly short time frame.

      MMMMM... Chocolaty Perl Goodness.....
Re: I Don't Know What I Need To Know
by trs80 (Priest) on Jun 05, 2003 at 23:56 UTC
    Knowing that you need to ask is the key. Everything beyond that is subjective.
Re: I Don't Know What I Need To Know
by BrowserUk (Pope) on Jun 06, 2003 at 00:54 UTC

    As Lord Bryon said "Knowing the right question to ask is half the answer."

    And someone (probably an inscruitable japanese gentleman) said: "Each journey begins with the first step". (Or maybe it was an American and "Each journey begins when you step on the gas":).

    And one of my old bylines which might have been original, but maybe not, went: "The hardest thing is not knowing what it is that you don't know".

    The upshot is, simply recognising that you need to gain more knowledge is the start. From there you have several alternative routes. Sticking to coding so as to keep this vaguely on topic.

    Traditionally, the route was 'plan, design, specify - then code'. This has some advantages, but I've seen several, large, highly specified and well designed projects fall behind schedule, go way over budget and ultimately flounder because seemingly insignificant details in the original specifications were based upon assumptons. mistakes or simply overlooked. Later, these proved to be so intractable or required so much reworking of the layers above to correct, that it was economically infeasible. (Anyone heard of or remember Nimrod?).

    Thats why I personally prefer the RAD approach to development. Get as much as you can going as quick as you can, skipping the nice-to-haves and foregoing some "best practices" if need be, at the same time as the specification is being drawn up. The idea is not to produce great code or a complete product, but to simply prove the concept will (or can) work from top to bottom. Often, this can result in simplification, where certain "obviously desirable" features prove to be unneeded or unworkable. To me, the value of such a first-cut piece of throw-away code is often way undervalued.

    Relating this all back to the asking of questions. Recognising that you are almost certainly not the first person to try and do what you are doing, means that if you can get the willing ears of a sufficiently large group of your peers (coders in similar fields), then asking "the question" can often save you a large amount of effort pursuing (whether through books, reading code or prototyping) the wrong direction. Sometimes just asking the most basic question of such a peer group can get you pointed in the right direction.

    Hence the true value of the interactive nature of PM:)

    Of course, there will always be those who won't hear or will simply ignore the answers, but noone should be afraid to ask their question -- at least once.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


      As one of my all time favourite quotes says:
      Where a new sytem concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.
      — Frederick P. Brooks, Jr.

      Makeshifts last the longest.

Re: I Don't Know What I Need To Know
by ihb (Deacon) on Jun 23, 2003 at 12:48 UTC

    I, as you and many other, have been thinking the same. But I realized that I could find out what part of Perl I wasn't knowing. I took a look at perl.pod. I looked at each title and thought "Do I know this document inside out, or don't I?" Then I knew what fields in Perl I didn't know. And then I did the same for the TOC in those documents I believed myself to know. I of course didn't know everything in them. :)

    I didn't read everything I realized I didn't know. Some things seemed like they weren't relevant to me at the time being. But I knew it was there, and if I felt I needed it I knew where to look. So after doing this, I was much better at asking myself the right questions.

    Just my angle,
    ihb

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2014-12-28 19:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (182 votes), past polls