Re: What do you know, and how do you know that you know it?

[xdg]

My initial reaction was "what does this have to do with Perl?" However, it suddenly occured to me that there is an obvious (to me, at least) Perl corollary:

There is more than one way to do it

From different starting points, reasonable people will reach very different conclusions on how to solve problems. This is normal and natural. The importance, ease, and cultural encouragement of testing as part of code writing is another parallel -- what do you know your code does and how do you know it? -- or at least, what do you assume you know about your code and how do you check your assumptions. (Does this suggest the Perl community is naturally inclined to avoid the self-reinforcing belief trap?) Now, if only there were a Test::More suite for life...

In all seriousness, to the point of the article, I find one of the best ways to avoid a self-reinforcing belief system is the debating team notion that one should be able to argue both sides of any argument equally well.

[tilly]

I actually started with the plan of ending with a discussion of some of the self-referencing belief systems dividing programmers (eg dynamic techniques vs B&D practices), but ran out of steam. (It was late at night...)

However let me assure you that while TIMTOWDI encourages questioning how you do things, nothing protects anyone from falling into this type of trap. Not even being a Perl programmer. To the extent that you can be protected, one of the best protections is to be painfully aware of how easy it can be to flip the bozo bit on information that would change your views, and give the alternatives careful consideration.