Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

The path to mastery

by tilly (Archbishop)
on Aug 06, 2000 at 05:28 UTC ( [id://26380]=perlmeditation: print w/replies, xml ) Need Help??

This is not a story about Perl. Or Perl programming. Or even computers.

Rather it is a story about the road to mastering any logical subject.

As my bio says, I once studied math. One subject in math is analysis. This is the true story of a student that my first analysis professor once had.

This student was a physics student. He did not really want to take analysis. But he decided that if he was taking it, then he might as well truly learn it.

When he sat down to do his first homework he realized that he did not understand what it meant to prove something. So he went to the professor and asked what a proof was. The professor answered, "A proof is an airtight demonstration that a thing must be so." The student asked what could be assumed. The professor answered, "You may start with the axioms and the theorems we have proven from the axioms." The student asked if you had to accept the theorems, the professor said, "You need not accept anything that you have not been fully convinced of."

The student's first homework set was 20 pages long. The other students needed 5. The student was concerned and asked the professor, "My homework is so much longer than theirs is. Am I doing something wrong?" The professor said, "You may take as long to do it as you need to. Did you keep in mind what I said about axioms and theorems?" The student answered, "I did, but I didn't feel that I understood the theorems so I worked from the axioms only." The professor answered, "That is good but learn to build on what you already know." The student promised to try.

The student's first homework was perfect. As the course progressed the student continued to try. Homework by homework he maintained excellent work, and step by step learned to organize his thoughts so that he could build on previous results in class and in his own work. And step by step the length of his homework fell.

By the end of the course the other's still needed 5 pages for their homework. But this student did not. He no longer needed 20. He no longer needed 10. Instead his perfect assignments fit comfortably on a page with room to spare.

The professor congratulated him on his progress and asked him about the cause. The student said, "Well I know the subject so well that I know exactly how to do each problem, and I do that and no more."

Here then is the moral for Perl programmers. When you see the code of master Perl programmers you may be amazed at how few strokes of the keyboard they require to solve a problem completely. Many in error think that they should therefore constantly try to cram as much into as little room as possible.

This is a misguided path.

Instead strive to understand fully and completely the tool at hand. Explore exactly how it works and what it can do. In addition constantly learn how to build on what you and others have done before. Aim for clarity and comprehension, and mastery shall surely follow.

This is a true path.

Replies are listed 'Best First'.
(jcwren) RE: The path to mastery
by jcwren (Prior) on Aug 06, 2000 at 06:18 UTC
    Instead strive to understand fully and completely the tool at hand. Explore exactly how it works and what it can do. In addition constantly learn how to build on what you and others have done before. Aim for clarity and comprehension, and mastery shall surely follow.

    First, let me say that exploring a langauage and it's capabilities is a Good Thing. Make no mistake about that. Any correct (i.e. non-Cargo Cult) knowledge is good knowledge. But knowledge is also knowing how, when, and where to apply it...

    So, while these are noble goals, I don't place a lot of faith in them being attainable in the real world. Using the minimum code to accomplish a task is of no value if the next person to come behind you can't maintain it. When I leave my job, I don't expect the company to be able to hire a Larry Wall, a btrott, or a merlyn. Instead, I hope to have written my code where an *average* programmer can maintain it. Because companies can't afford industry stars to support upgrades, changes, and fix (Dog forbid) bugs.

    I believe the code should be well structured, well documented, and well designed. But not so tight that if I need to insert a debugging line, that I have to unroll 8 loops, 2 map statements, and a sort, just to print some keys to verify data.

    What are my qualifactions? I've been writing code for 20+ years. I started in BASIC, learned APL, Fortran, COBOL, Forth, 'C', C++, Pascal, Logo, Perl, 14 different assembly langauges, and Dog knows what else. I'm not saying this to brag. I've had to solve problems in all these langauges, at one time or another. I do embedded systems, Windows apps, device drivers, and web-based applications. I don't want to learn a language *so* well, that it's to the exclusion of others. I have too many environments to work in. I'll probably never write Perl as tight as a lot of the people here. I'll probably never get as good at regexps as Ovid has. I'm a generalist.

    To me, good code is not code that exploits obscurities of a language, or uses methodologies so unusual, you're not even sure the language supports it. No, good code is code that uses mainstream idioms whereever possible, algorithms that are well documented, and the source can be modified without fear of breaking everything else it depends on. A good book towards this subject is The Pragmatic Programmer by Hunt and Thomas. Another is The Practice Of Programming by Kernigan and Pike.

    I do believe that in an ideal world what you say is true. But the reality of marketplaces, workforces, and our generally lousy education system really don't make such an implementation practical.

    As an aside, if anyone I hire writes code that only they can maintain, because it's either so good, or so bad, they're out of there. I don't have time for prima donnas, nor incompentents. I want good people, that are flexible, adaptable, and not super-stars. Because someone *else*, sooner or later, is going to be working on that code. As further proof of this theory, take a look on SlashDot, referrencing the people that write and maintain the 400,000+ lines of code for the Space Shuttle. They're 9-to-5, average, disciplined people. Not stars.

    --Chris

    e-mail jcwren
      You make some very good points.

      However I would like to return by saying that when you read the code that top Perl programmers write when it counts, people like merlyn and Tom Christiansen, that code does not take a genius to understand.

      I feel that if there are not at least 3 other people at my job who could pick up and understand my code (I work at a small shop), then I am doing something wrong. That does not mean that I should not constantly strive to write better code. It means that I need to find a balance between my taking advantage of more knowledge and my having made sure that people I am mentoring understand the features I use.

      I pity any C programmer who tries to maintain code where I in different sections switch from object oriented to functional to straight procedural code. (Not all at once, each in the place in the system where it fit properly.) I would not pity the person who taught me how to use those ideas, nor the two others who I personally brought up to speed on Perl.

      YMMV. TIMTOWTDI because different ways fit different situations best. And definitely questions about who will have to understand it next play a valid role. (If you read through my previous responses you can see what my code looks like. I am no Randall, but make your own mind up about whether you find it legible.)

      Why not write ultra tight code if you document it well?
      If your co-workers read your documentation then they will understand
      Maybe even learn something?
      Just a thought



      lindex
      /****************************/ jason@gost.net, wh@ckz.org http://jason.gost.net /*****************************/
        Why not write self-documenting code?
        In my opinion programmer's goals should be: efficience, maintainability, readability. Not necessarily in this order :)
        Artificial languages are supposed to be used to communicate with humans, not only with machines.
        see you
        Larsen
      I can groove on this. I suppose the one exception would be where there is a cost to pay in performance if you do not take an obscure yet effeicent route. Certainly you need to balance the performance/obfuscation ratio, but sometimes I would think that there would be exceptions.

      redmist
      redmist.dyndns.org
      redmist@users.sourceforge.net
RE: The path to mastery
by Anonymous Monk on Aug 07, 2000 at 19:29 UTC
    So I've been puzzling over this for a little while, trying to think of why it seems so familiar. And after wracking the brain for a while, it comes back to something monk-like :
    ...Therefore the Master steps back so that people won't be confused. He teaches without a teaching, so that people will have nothing to learn. (from the tao te ching)
    but that's only part of it; isn't there a simple koan that says "increase, then decrease"? Can anyone come up with a reason as to why all of the teacher's students didn't recieve the same advice?
      The teacher gave the best advice he knew how to. By the time I went through that class his advice had improved to starting with telling us that story when he tried to explain what a proof was. I am not sure how many students took it to heart though.

      (How do you think I heard it? :-)

      If anyone is curious, this is a true story. I have changed the wording somewhat (mainly because my memory is fallible so I don't remember the original wording). I heard it from the professor's mouth, on or about the first day of my intro to real analysis class, Fall of 1990, at the University of Victoria. The professor in question was Bill Pfaffenberger.

        yo bro Not sure you will get this, and even less sure this is the correct forum for a personal message but there does not seem to be much to lose, so send me something at Noraadraw@hotmail.com so I will have a correct e-mail address. Ant
      Did the other students ask any questions?
        Having also studied math, my experience is that they probably didn't. Less than 1% of the students I have ever come across in any subject have cared enough about the sheer act of learning to ask questions. The rest were there for a piece of paper, and nothing more.

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Re: The path to mastery
by pajout (Curate) on Mar 23, 2011 at 15:28 UTC
    I completely agree... Just adding an example why tight code is not proper in every case.
    Once I had to tune and slightly change algorithmic part of some data processing sw. Though I knew required new behaviour, I did not know definition or description of already implemented behaviour. And it was horrible journey with many many questions of type "Yes, I understand what it does, but if this and that is undefined, result should not be correct - is it mistake or is it wanted or it does not matter?"
    Of course, missing documentation is the point, but more simpler, more primitive code could help me. Simpler variant of my speech could be "Yes, I understand what the code does, but why?"
      I believe this thought reveals the truth of Fred Brooks's famous aphorism that there is "no silver bullet" when it comes to managing complexity in software. There is no shortcut to comprehension. Comments can only help a certain amount, whether they be written by/for the original programmer, or someone following them. Often they actually cloud things, or are a distraction, and often do not keep up with the code as it itself is changed.

      The proof of this is in coming back to a piece of code written by yourself or another, and trying to understand why it behaves in a particular (wrong) way when it shouldn't. By definition, comments (and indeed code) are written with the amount of understanding available to the programmer(s) at the time they wrote it, which is by definition finite. There is no shortcut to simply putting in the effort to understand what it is actually doing.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (3)
As of 2024-10-03 13:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The PerlMonks site front end has:





    Results (42 votes). Check out past polls.

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.