http://qs321.pair.com?node_id=26389


in reply to The path to mastery

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

Replies are listed 'Best First'.
RE: (jcwren) RE: The path to mastery
by tilly (Archbishop) on Aug 06, 2000 at 06:47 UTC
    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.)

RE: (jcwren) RE: The path to mastery
by lindex (Friar) on Aug 06, 2000 at 18:29 UTC
    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 strive to write self documenting code, but I also like to fill in with helpful comments. When I use a code snippet that I had to look up, I usually put a comment in explaining it. This leads to the funny situation of going back to maintain a bit of code written months prior, and finding comments like, "@_ is the input array to the subroutine" just before a line like "my ( $name, $rank, $serialnumber ) = @_;". I didn't know that when I wrote it, but I do now. Someone new to perl will appreciate that line when they have to work on the code, but an old timer would think it was written by an idiot. (No, not an idiot. A newbie... but sometimes we mistake ignorance for idiocy)

        But yes, writting self documenting code is very important. Thats why I use constant.pm instead of writing the routines myself and why I didn't use a regex in my answer to One for the regexp fans

RE: (jcwren) RE: The path to mastery
by redmist (Deacon) on Aug 08, 2000 at 11:05 UTC
    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