Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Re: Second rate programmers and my confession

by BUU (Prior)
on Jun 05, 2002 at 21:10 UTC ( #172011=note: print w/ replies, xml ) Need Help??


in reply to Re: Second rate programmers and my confession
in thread Second rate programmers and my confession

I fail to see why using 'higher level' terms is symptomatic of a lack of ability. Perhaps the first doctor felt that "idiopathic self-limiting condition" gave you the most succinct and explanatory description. Perhaps it does so for him, and he would consider "it gets well on its own" a poor statement because it does not explain or teach as much as the previous one. My point being, that people will use what ever terms come naturally to them to explain their project. If you had to describe something, and there was a 5 syllable word that exactly explained it, you could use that, or perhaps you could use 4 or 5 sentences of 'lower level words' and still not have fully explained it.

We could go even further in this analyzation, and say that perhaps the first doctor respected you and your intelligence, so he used advanced terms that precisely defined the problem, where as the 'top surgeon' did not feel the same level of respect and felt he had to "dumb down" the explantion for a "lay man".


Or of course, i could be wrong. But people use whatever language they feel comfortable with, unless they are making a deliberate effort to reach a different level, either higher or lower.


Comment on Re: Re: Second rate programmers and my confession
Re: Re: Re: Second rate programmers and my confession
by Beatnik (Parson) on Jun 05, 2002 at 21:22 UTC
    There's also the chance the first doctor didn't really know what he was saying exactly, he might've just remembered a term from a book and couldn't explain the true cause (neither could the second doctor ofcourse)

    Greetz
    Beatnik
    ... Quidquid perl dictum sit, altum viditur.
Re: Re: Second rate programmers and my confession
by George_Sherston (Vicar) on Jun 05, 2002 at 21:38 UTC
    update poop scoop - this was meant to be a reply to the reply to my first reply...

    It's possible. But my take on that particular situation, and my generalisation from that and other observations, is that obscure jargon often (though by no means always) goes with weak thought and insecurity.
    (A) using a technical term gets one off the hook of explaining what one really means - maybe one does in fact know; but maybe one doesn't want to find out that one can't put it more simply. Certainly, if I can put my concepts into terms that the intelligent generalist can understand, then I can be fairly sure I have understood them, rather than merely having learnt to say their names in a convincing way.
    (B) In any event, if I really *am* uncertain about what I'm doing, then one way I may want to hide this, and make myself feel cleverer, is by dressing up the little I know in language that distinguishes it from ordinary knowledge.

    I'm often reminded of Richard Feynman, whose ability to put complicated concepts into everyday language seemed to me to be part of his genius - certainly an outworking of his ability to understand.

    George Sherston
Re: Re: Re: Second rate programmers and my confession
by Ovid (Cardinal) on Jun 05, 2002 at 21:40 UTC

    BUU wrote: I fail to see why using 'higher level' terms is symptomatic of a lack of ability.

    It may not indicate lack of ability, but oftimes, it is often indicative of communication problems. One company I worked at had a programmer who would deal with problems like this:

    
    Customer:    Why didn't I get my reports?
    Programmer:  I just checked and you got a SOC7 in GLJ0430R and I'm going to
                 have to reload the dataset and start from the top.
    

    That programmer was technically correct. Of course, he didn't answer the customer's question. Learning to target your message to your audience is important. I would have simply said "looks like we got some bad data. I'm going to fix it and have the report to you in an hour."

    Now, does the previous person have a "lack of ability"? I remember one professor who said "if you can't put it in writing, you don't know it." Quite often, if I find that I can't explain something in clear terms that anyone can understand, I really don't understand what I'm trying to explain.

    What's a SOC7? Well, it's a SOC7. It's...it's... it's a data exception. What is a data exception? Well, it's, uh, you know...

    You see my point? If I can't explain something clearly, I probably don't understand it. Of course, I may understand it very well, but simply be a poor communicator. I tend to be suspicious of those who want to use high-falutin' terms.

    Hope that helps :)

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

      While i take your point about poor communications, i could ask "Why is a programmer doing customer relations/support?". Ideally you would have someone trained to 'interface' between the customer and the programmer. Or atleast thats my take on it etc. etc.

      I could also point out that 'technical terms'(etc.) are also fufilling number one of the programmers..motto? Namely lazyness. Why use a paragraph when 2 words will do?

      Course, doctors are expected to have a 'nice bedside manner', although i have to admit i would prefer competency over 'charm'..
        Part of being a programmer should be communicating clearly to your peers. Your peers can be other programmers, managers, and even clients. If you can't speak in terms they can understand, you're not being helpful, and especially, you're not being very effective.

        When the other party can't clearly understand what you're saying, they are more likely to misinterpret it. That misunderstanding will probably return in the form of demands that are unrealistic, impossible, or, in your opinion, just plain stupid. Since you can't explain clearly why these requests are unrealistic, impossible, or some diplomatic euphemism for "stupid", then no matter what you say, they think you're making a big deal out of nothing. You're upset at their requests, and they're upset at your nonsensical complaining.

        The classic "rift" in tech companies seems to between sales/marketing and the technical department, usually programmers and engineers. They are, from a psychological perspective, about as incompatible as you can get.

        When "sales and marketing" people talk to "the techies", they speak their own "sales and marketing" language, and not surprisingly, the reverse is true. In order to be effective, both sides must make an effort to bridge that gap, and one of the easiest ways to do this is to use plain language. If both sides refuse to compromise, you might as well have one group speaking Swedish and the other Korean. Nothing is going to be communicated except vague notions of what the problems and requirements are, and both sides feel abused.

        In line with your "number one programmers motto", think of that in terms of the collective, not on an individual level. If Party A communicates something to Party B in 10 seconds, but it takes Party B five minutes to figure out what Party A really said, is that productive? If Party A instead took 30 seconds to give a full explanation, then it would end there. It's about conserving effort on a broader scale.
      I agree: to quote Einstein: "If you can't explain something to a six year-old, you don't understand it yourself". Even though most of us (here) are reasonably technically proficient, I think (huge generalization coming up) that even we find it easier to understand things that are written in a natural language - after all, natural language is the tool we use every day.

      One of the arts of communication is tailoring your output to the audiences' level of comprehension - if you're talking to your non-programmer manager, you'd hopefully use language that he/she could understand. Trying to "blind with science" tends to make you appear arrogant, and will often alienate your audience. If that audience has some influence on your wage-packet, I'd watch out.
      As programmers, we generally have a higher level of technical knowledge than the average (customer, user, individual), but giving descriptions in "user-language" actively helps your ability to communicate.
      My 2 cents, take with the appropriate quantity of sodium chloride.

      davis
      Is this going out live?
      No, Homer, very few cartoons are broadcast live - it's a terrible strain on the animator's wrist
        If you can't explain something to a six year-old, you don't understand it yourself

        Yeah, he also said at one moment that only 4 or 5 people in the world understood his general theory of relativity. I don't think Einstein meant he had explained his theory to the kids in the neighbourhood.

        Would you think that Einstein himself didn't understand his theories?

        Abigail

      I don't know what your point is. Perhaps you are trying to say that the programmer didn't understand the problem. But you didn't tell us what happened after the programmer talked to the customer. Did he screw up and the customer never got his report? Or did the customer get his report after the data was reloaded? In the latter case, I'd say the programmer did understand the problem.

      I strongly disagree that you don't understand a problem if you cannot explain it in a few sentences to someone totally unfamiliar with the field, and who has no interest in knowing.

      After I graduated, I did a few years of theoretical research at a university. The first nine months I spend studying topology before I could understand some of the problems I was working on. Was I a bad researcher because I won't be able to explain the problems here on this webboard? I don't think so.

      If all people who really understood things well all could easily explain things to other people regardless of their level, the quality of education would be much better. I've seen people, top of their field by a large margin, who write very hard to understand papers. That doesn't make them second rate.

      Abigail

        Abigail-II wrote:

        I strongly disagree that you don't understand a problem if you cannot explain it in a few sentences to someone totally unfamiliar with the field, and who has no interest in knowing.

        I would completely agree with that statement except for one little point; you appear to imply that I said that. I didn't.

        If you read my post again, you'll see that I chose my words most carefully:

        1. ...but oftimes, it is often indicative of communication problems.
        2. That programmer was technically correct.
        3. Quite often, if I find that I can't explain something in clear terms ...
        4. If I can't explain something clearly, I probably don't understand it.

        As you can see from the above quotes, I was extremely clear not say "all", "any", "none", or nonsense like that.

        You said you don't know what my point is, so I will try to be a bit more clear. Considering that jargon can be confusing to those who don't understand it:

        • Some people prefer to use jargon to discuss an issue.
        • Those who use jargon often don't know how else to express the issue.
        • If they don't know how else to express an issue, sometimes they have no understanding of it beyond the jargon.
        • Therefore, some people who prefer to use jargon have no understanding of an issue beyond the jargon.

        While the above is a bit wordy, it's logically valid. Of course, some will call it wishy-washy, which it is because if I only found one person who fit, then my case is proved :) The best I can do is sum it up this way: it's been my personal experience that those who communicate poorly by only using jargon are usually either showing off or they don't truly understand what they're talking about.

        That was all I was saying. Nothing more. And as for the programmer I mentioned? He was always complaining about getting bad reviews, even though "he knew more than the customer". He couldn't understand why he wasn't getting promoted. Communication is more than just saying words that are correct.

        Cheers,
        Ovid

        Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        I interpreted the point more as in: if you're not talking to "fellow experts", it's more productive to explain things in plain language, even when that implies simplifying a lot of "unimportant" things.

        Simplifying a difficult problem without losing track of the important points is hard, maybe even harder than going into all the little details that make up the problem, and people who can do it effectively usually have a lot of knowledge in that field. And some skill at "talking down" :-)

        Anyway, it's good to see you here again :-)

Re^3: Second rate programmers and my confession
by tadman (Prior) on Jun 06, 2002 at 08:04 UTC
    Using "higher level" terms is, if not symptomatic, then at least strongly related to having "a lack of ability", as you put it.

    There is a theory of skill development which goes something like this:
    • Unconciously Incompetent
    • Conciously Incompetent
    • Conciously Competent
    • Unconciously Competent
    This is very similar to many Eastern philosophies regarding the path of learning.

    I have a feeling that when one progresses to the fourth step, there is no reason to talk in scientific terms or to use fancy words. Since a master understands the subject matter in a complete sense, that it is really an integral part of them, there's no reason to use symbolic references to advanced concepts, such as the example of "idiopathic". It's not "dumbing down" so much as not making it sound more complicated than it is.

    It is a natural tendancy for some people, especially those of intermediate skill, to start talking technical nonsense just to sound important. Anyone who knows what they are saying will find it devoid of real meaning, and anyone who doesn't will find it useless. It's only those that have an idea of what they are saying that will be impressed.

    PROGRAMMER A: Your hash reference buffer has no entries, so that must be why you're not getting any program output.
    PROGRAMMER B: I think what he's saying is that your document is empty, so that's why the page is blank.
doctors, Re: Second rate programmers and my confession
by amarceluk (Beadle) on Jun 06, 2002 at 13:02 UTC
    This is off-topic Perl-wise, but does relate to the discussion at hand.

    I don't think "best doctors" necessarily means "doctors with best medical ability"; however, there's more to being a good doctor than knowing a lot about medicine. IMO, the best doctors are the ones who not only have good medical ability, but can relate to patients, tell them what's wrong with them in terms they can understand, explain the treatments and how they work, and basically make the patient feel like a human being rather than a collection of symptoms. That's how I'd interpret it, anyway.

    __________
    "Abby-somebody. Abby-normal."
    Young Frankenstein
Re: Re: Re: Second rate programmers and my confession
by breakwindows (Scribe) on Jun 10, 2002 at 15:19 UTC
    I fail to see why using 'higher level' terms is symptomatic of a lack of ability

    In lieu of the discussion about this, I'd like to throw in my own ammendment to the original statement.

    Very learned persons, in any field, can be detached in a certain sense. To them, these complex and lotsa' syllable words aren't big or confusing, so it is a detached language. With Perl, however, a true expert can see the beauty of the language is in it's simplicity. Sure, it looks like hell from time to time, but the concepts are extremely simple, to the point of common sense. This holds true for almost anything; math, science, computers - it all comes down to ones and zeroes.

    Take science, for example. Someone told me they had no idea of the point of Quantum Mechanics. I could have gone into big words or explanations, but instead I asked, "How wide is that doorway?". They answered something in the range of 4 feet, and I corrected them: "No, the doorway is (closed one eye and held up two fingers) this wide. It would only be that wide if I was standing over there, but I'm not. And if I went over there, I'd have to ask again". I think this is what I think the original post intended...there's no ego, no pretension, just pointing out what persons were trying too hard to see (and are fully capable of seeing). Everything can be simple, you just have to know how to look.

    But I do agree with this parent's main point: assuming a lack of expertise based on any generality is wrong. We should, however, strive to see how easy and basic we can make anything we take on...after all, isn't that the point of Perl? ;)

    --
    complexity kills.
Re^3: Second rate programmers and my confession
by radiantmatrix (Parson) on Jul 05, 2006 at 18:33 UTC

    Concisely put, someone who has a deep knowledge of something gains, as a result, the capacity to appropriately hide its complexity through simple metaphor.

    When someone doesn't understand as well, he or she cannot as easily extrapolate a simple metaphor, and can only give a technical answer.

    When someone doesn't understand at all, he or she might simply hide behind impressive-sounding words.

    This is largely because the knowledgeable individual is much more confident about leaving out technical details, because he or she knows which details are unimportant for a given context. The less-knowledgeable has not not yet developed a feel for which technical details are really important in understanding a given concept.

    So, while an explanation filled with technical detail doesn't automatically mean the speaker/author is not knowledgeable, it does tend to work out that way.

    <radiant.matrix>
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (11)
As of 2014-07-30 20:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (240 votes), past polls