Frustration

chromatic on 2003-01-19T22:21:07

What is it in the Perl community that makes presumably otherwise reasonable people unable to address high-level ideas, instead attacking minutiae?


Yes, what ?

rafael on 2003-01-19T22:24:55

I asked myself a similar question recently. Probably in similar circumstances ?

But what color is the bike shed?

brian_d_foy on 2003-01-20T01:09:34

This problem has nothing to do with Perl. You will find the same thing in almost every community. That is, we do not get to blame Perl, which is a good thing. :)

I do not know the situation that frustrates you, but Kurt Starsinic (or maybe Ziggy) says frequently "they're building a bike shed", meaning that people who do not see the big picture (and not always for lack of intelligence) focus on the things they can easily grasp---the minutia.

Code before design?

Louis_Wu on 2003-01-20T06:37:14

I wish that I really knew why, but I have noticed that many coders tend to try code before thinking about something. I first noticed this on Slashdot, and have since come to expect it from all new/young/inexperienced coders. It may be because they first learned to do something before learning the best way to do anything.

"Wow, I can make the text on this web page blink." They don't know better, and they don't think about other ways to do it. They don't see how irritating it is to try reading an entire paragraph of blinking yellow text on a red background. For a color blind person.

As I teach myself a bit of programming, I'm trying to avoid that pitfall; I'm trying to learn about the big picture as well as the minutae - software design and syntax at the same time.

Re:Code before design?

jonasbn on 2003-01-20T09:11:46

Hands-on experience can be VERY good. I learned Perl from the book 'Learning Perl' and by coding.

I have made many mistakes and I still am, but at the same time my success rate has and is increasing.

So do not underestimate hands-on experience

Re:Code before design?

Louis_Wu on 2003-01-20T18:02:16

I understand hands-on experience, and I don't mean to underestimate it, but it is no substitute for theoretical knowledge.

I'm a Mechanical Engineer by training, and an Aeronautical Structures Engineer by trade - there are many experienced people (20+ years on the job) who don't have degrees, but can do most of the day-to-day work of an engineer. But you'll get a blank look if you ask them about the stress distribution in the part. Stress distribution and stress paths are critical to evaluating the safety and reliability of a part or assembly - someone needs to be able to decide if the design will work. And the 'practical engineer' can only evaluate part of the situation.

The practical experience is necessary, but the theoretical knowledge provides a framework within which that practical knowledge can be applied. My point about "code first, think later" isn't that practical experience is not needed, but that it needs to be paired with theoretical knowledge. That combination of theoretical and practical is what makes good engineers or programmers.

Examples?

jonasbn on 2003-01-20T08:26:37

It is quite a statement, could you give an example of what you mean?

Overuse of critical intelligence

jordan on 2003-01-21T02:55:17

People in the Perl Community tend to be very intelligent and often fall into what Edward de Bono (in de Bono's Thinking Course 1985 - Facts on File Publications - ISBN 0-8160-1380-2 (hc), 0-8160-1895-2 (pb)) calls the Intelligence Trap.

I won't go into depth about the Intelligence Trap, but one problem with intelligent people that the author notes is:

  • The critical use of intelligence is always more immediately satisfying than the constructive use. To prove someone else wrong gives you instant achievement and superiority. To agree makes you seem superfluous and sycophant. To put forward an idea puts you at the mercy of those on whom you depend for evaluation of the idea. So, too many brilliant minds are trapped into this negative mode (because it is so alluring).

So, many intelligent people get tied up in minutae, because it's easy to find fault in the details. Thinking about big ideas usually requires a lot more work.