Editing Open Sourcing the Virtues of a Perl Programmer (section)

== When Virtues Go Mad: A Chestertonian Warning ==

G. K. Chesterton observed that virtues become dangerous when they become detached from one another and “go mad.”<ref name="Chesterton1908" /> The same warning applies to the virtues proposed here. A complementary point is that a virtue can fail not only through excess, but through deficiency. The Perl community therefore benefits from examining both edges of each virtue rather than merely replacing one provocative vice-label with a more respectable word.

=== Practical Wisdom Between Shortsightedness and Overthinking ===

Practical Wisdom fails through deficiency when contributors repeatedly solve only the immediate problem: manual work is needlessly repeated, local fixes accumulate, documentation is deferred forever, and nobody considers the future maintainer. It fails through excess when deliberation becomes an end in itself: architectures are designed for hypothetical futures, abstractions multiply faster than users, and “best practice” becomes a reason that no imperfect but useful solution may ship.

The virtuous mean is not mediocrity. It is proportionate judgment — enough foresight to reduce needless future cost, enough restraint to keep the solution answerable to the problem that actually exists.

=== Spiritedness Between Apathy and Combativeness ===

Spiritedness fails through deficiency when a contributor simply stops caring. Bugs linger because they are someone else's problem; newcomers go unanswered; a useful distribution decays because nobody feels responsible for it; a damaging assumption survives because challenging it would require effort. Open source cannot flourish on indifference.

The excessive form is equally familiar: urgency becomes contempt, technical disagreement becomes moral combat, and advocacy becomes a personal crusade. The Perl community has always contained strong personalities and strong opinions; the virtue is not the elimination of that energy but its discipline toward repair, truth, and the good of the community.

=== Good Order Between Neglect and Stagnation ===

Good Order fails through deficiency when there is no dependable structure to inherit: code is clever but opaque, release practices live only in memory, documentation is stale, ownership is unclear, and useful conventions exist only as oral tradition. Such disorder eventually makes contribution harder even for talented people.

Good Order goes mad when structure protects itself. Processes multiply because processes already exist; stylistic purity outweighs usefulness; governance becomes inaccessible to newcomers; experimentation is treated as a threat. What began as an attempt to make collaboration easier can become a barrier to collaboration. The right kind of order is therefore ordered again toward people and useful work.

=== Why Both Extremes Matter ===

Deficiencies are often easier to recognize because something visibly fails to happen: a bug is not fixed, a module is not maintained, documentation is not written. Excesses can be more dangerous precisely because they can masquerade as excellence. Over-engineering can call itself wisdom; aggression can call itself commitment; bureaucracy can call itself quality. Naming the virtue correctly is therefore only the beginning. The community must also remember the end for which the virtue exists.

Balanced together, Practical Wisdom, Spiritedness, and Good Order form a stable foundation for Perl craftsmanship and community stewardship. Diligence, Patience, and Humility help keep those powers integrated. The goal is not to make Perl programmers less energetic, less ingenious, or less opinionated. It is to direct those strengths toward work and relationships in which people can flourish.