diff --git a/sections/chapter_08.pod b/sections/chapter_08.pod
index b71a7c6f..6b0cb42f 100644
--- a/sections/chapter_08.pod
+++ b/sections/chapter_08.pod
@@ -1,17 +1,18 @@
 =head0 Style and Efficacy
 
-Programming and programming I<well> are related, but distinct skills.  If we
-only wrote programs once and never had to modify or maintain them, if our
-programs never had bugs, if we never had to choose between using more memory or
-taking more time, and if we never had to work with other people, we wouldn't
-have to worry about how well we program.  To program well, you must understand
-the differences between potential solutions based on specific priorities of
-time, resources, and future plans.
+Quality matters.
 
-Writing Perl well means understanding how Perl works.  It also means developing
-a sense of good taste.  To develop that skill, you must practice writing and
-maintaining code and reading good code.  There are no shortcuts--but you can
-improve the effectiveness of your practice by following a few guidelines.
+Programs have bugs. Programs need maintenance and expansion. Programs have
+multiple programmers.
+
+Programming well requires us to find a balance between getting the job done and
+allowing us to do so well into the future. We can trade any of time, resources,
+and quality for any other. How well we do that determines our skill as
+pragmatic craftworkers.
+
+Understanding Perl is important. So is cultivating a sense of good taste. The
+only way to do so is to practice maintaining code and reading and writing great
+code. This path has no shortcuts, but this path does have guideposts.
 
 L<style>
 
diff --git a/sections/exceptions.pod b/sections/exceptions.pod
index 70e36703..0159cac7 100644
--- a/sections/exceptions.pod
+++ b/sections/exceptions.pod
@@ -1,27 +1,23 @@
 =head1 Exceptions
 
 Z<exceptions>
-
-Programming would be simpler if everything always worked as intended.
-Unfortunately, files you expect to exist don't.  Sometimes you run out of disk
-space.  Your network connection vanishes.  The database stops accepting new
-data.
-
 X<exceptions>
 
-Exceptional cases happen, and robust software must handle those exceptional
-conditions.  If you can recover, great!  If you can't, sometimes the best you
-can do is retry or at least log all of the relevant information for further
-debugging.  Perl 5 handles exceptional conditions through the use of
-I<exceptions>: a dynamically-scoped form of control flow that lets you handle
-errors in the most appropriate place.
+Programming well means anticipating the unexpected. Files that should exist
+don't. That huge disk that will never fill up does. The always-on network
+isn't. The unbreakable database breaks. Exceptions happen, and robust software
+must handle them.  If you can recover, great! If you can't, log the relevant
+information and retry.
+
+Perl 5 handles exceptional conditions through I<exceptions>: a
+dynamically-scoped control flow mechanism designed to raise and handle errors.
 
 =head2 Throwing Exceptions
 
 Z<throwing_exceptions>
 
-Consider the case where you need to open a file for logging.  If you cannot
-open the file, something has gone wrong.  Use C<die> to throw an exception:
+Suppose you want to write a log file. If you can't open the file, something has
+gone wrong. Use C<die> to throw an exception:
 
 =begin programlisting
 
@@ -42,16 +38,15 @@ X<exceptions; C<die>>
 X<C<$@>>
 X<exceptions; C<$@>>
 
-C<die()> sets the global variable C<$@> to its argument and immediately exits
-the current function I<without returning anything>.  If the calling function
-does not explicitly handle this exception, the exception will propagate upwards
-to every caller until something handles the exception or the program exits with
-an error message.
+C<die()> sets the global variable C<$@> to its operand and immediately exits
+the current function I<without returning anything>. This thrown exception will
+continue up the call stack (L<call_stack>) until something catches it. If
+nothing catches the exception, the program will exit with an error.
 
 =begin sidebar
 
-This dynamic scoping of exception throwing and handling is the same as the
-dynamic scoping of C<local> symbols (L<dynamic_scope>).
+Exception handling uses the same dynamic scope (L<dynamic_scope>) as C<local>
+symbols.
 
 =end sidebar
 
@@ -61,17 +56,15 @@ Z<catching_exceptions>
 
 X<exceptions; catching>
 
-Uncaught exceptions eventually terminate the program.  Sometimes this is
-useful; a system administration program run from cron (a Unix jobs scheduler)
-might throw an exception when the error logs have filled; this could page an
-administrator that something has gone wrong.  Yet many other exceptions should
-not be fatal; good programs can recover from them, or at least save their
-state and exit more cleanly.
+Sometimes an exception exiting the program is useful. A program run as a timed
+process might throw an exception when the error logs have filled, causing an
+SMS to go out to administrators. Yet not all exceptions should be fatal. Good
+programs can recover from some, or at least save their state and exit cleanly.
 
 X<builtins; C<eval>>
 X<C<eval>; block>
 
-To catch an exception, use the block form of the C<eval> operator:
+Use the block form of the C<eval> operator to catch an exception:
 
 =begin programlisting
 
@@ -80,31 +73,19 @@ To catch an exception, use the block form of the C<eval> operator:
 
 =end programlisting
 
-As with all blocks, the block argument to C<eval> introduces a new scope.  If
-the file open succeeds, C<$fh> will contain the filehandle.  If it fails,
-C<$fh> will remain undefined, and Perl will move on to the next statement in
-the program.
+If the file open succeeds, C<$fh> will contain the filehandle. If it fails,
+C<$fh> will remain undefined, and program flow will continue.
 
-If C<open_log_file()> called other functions which called other functions, and
-if one of those functions threw its own exception, this C<eval> could catch it,
-if nothing else did.  There is no requirement that your exception handlers
-catch only those exceptions you expect.
+The block argument to C<eval> introduces a new scope, both lexical and dynamic.
+If C<open_log_file()> called other functions and something eventually threw an
+exception, this C<eval> could catch it.
 
-To check which exception you've caught (or if you've caught an exception at
-all), check the value of C<$@>:
-
-=begin programlisting
+X<magic variables; C<$@>>
 
-    # log file may not open
-    my $fh = eval { open_log_file( 'monkeytown.log' ) };
-
-    # caught exception
-    B<if ($@) { ... }>
-
-=end programlisting
-
-Of course, C<$@> is a I<global> variable.  For optimal safety, C<local>ize its
-value before you attempt to catch an exception:
+An exception handler is a blunt tool. It will catch all exceptions in its
+dynamic scope. To check which exception you've caught (or if you've caught an
+exception at all), check the value of C<$@>. As C<$@> is a I<global> variable,
+you should C<local>ize it before you attempt to catch an exception:
 
 =begin programlisting
 
@@ -114,14 +95,18 @@ value before you attempt to catch an exception:
     my $fh = eval { open_log_file( 'monkeytown.log' ) };
 
     # caught exception
-    if ($@) { ... }
+    B<if (my $exception = $@) { ... }>
 
 =end programlisting
 
 X<exceptions; rethrowing>
 
-You may check the string value of C<$@> against expected exceptions to see if
-you can handle the exception or if you should throw it again:
+Copy C<$@> to a lexical variable immediately to avoid the possibility of
+subsequent code clobbering the global variable C<$@>. You never know what else
+has used an C<eval> block elsewhere and reset C<$@>.
+
+C<$@> usually contains a string describing the exception. You can inspect its
+contents to see whether you can handle the exception:
 
 =begin programlisting
 
@@ -133,28 +118,45 @@ you can handle the exception or if you should throw it again:
 
 =end programlisting
 
-=begin sidebar
+Rethrow an exception by calling C<die()> again. Pass the existing exception or
+a new one as necessary.
 
-Copy C<$@> to C<$exception> to avoid the possibility of subsequent code
-clobbering the global variable C<$@>.  You never know what else has used
-an C<eval> block elsewhere and reset C<$@>.
+X<exceptions; throwing objects>
+X<exceptions; custom classes with C<Exception::Class>>
+X<C<Exception::Class>>
 
-=end sidebar
+You may C<die> with either a string or a reference--even an I<object>. Applying
+regular expressions to string exceptions can be fragile. Objects are more
+robust; they contain more information. You can throw any object as an
+exception, but consider using the CPAN distribution C<Exception::Class> to
+define your own class or classes of exceptions:
 
-Rethrow an exception by calling C<die()> again, passing C<$@>.
+=begin programlisting
 
-X<exceptions; throwing objects>
+    package Zoo::Exceptions
+    {
+        use Exception::Class
+            'Zoo::AnimalEscaped',
+            'Zoo::HandlerEscaped';
+    }
 
-You may find the idea of using regular expressions against the value of C<$@>
-distasteful; you can also use an I<object> with C<die>.  Admittedly, this is
-rare.  C<$@> I<can> contain any arbitrary reference, but in practice it seems
-to be 95% strings and 5% objects.
+    sub cage_open
+    {
+        my $self = shift;
+        Zoo::AnimalEscaped->throw unless $self->contains_animal;
+        ...
+    }
 
-X<exceptions; custom classes with C<Exception::Class>>
-X<C<Exception::Class>>
+    sub breakroom_open
+    {
+        my $self = shift;
+        Zoo::HandlerEscaped->throw unless $self->contains_handler;
+        ...
+    }
+
+=end programlisting
 
-As an alternative to writing your own exception system, see the CPAN
-distribution C<Exception::Class>.
+Catch these exceptions as you would any other exception.
 
 =head2 Exception Caveats
 
@@ -162,42 +164,42 @@ Z<exception_caveats>
 
 X<exceptions; caveats>
 
-Using C<$@> correctly can be tricky; the global nature of the variable leaves
-it open to several subtle flaws:
+Using C<$@> correctly requires you to navigate several subtle risks:
 
 =over 4
 
-=item * UnC<local>ized uses further down the dynamic scope may reset its value
-
-=item * The destruction of any objects at scope exit from exception throwing
-may call C<eval> and change its value
+=item * UnC<local>ized uses further down the dynamic scope may modify C<$@>
 
 =item * It may contain an object which overrides its boolean value to return
 false
 
-=item * A signal handler (especially the C<DIE> signal handler) may change its
-value when you do not expect it
+=item * A signal handler (especially the C<DIE> signal handler) may change
+C<$@>
+
+=item * The destruction of an object during scope exit may call C<eval> and
+change C<$@>
 
 =back
 
 X<exceptions; handling safely with C<Try::Tiny>>
 X<C<Try::Tiny>>
 
-Writing a perfectly safe and sane exception handler is difficult.  The
-C<Try::Tiny> distribution from the CPAN is short, easy to install, easy to
-understand, and very easy to use:
+Perl 5.14 improves the safety of exception handling. The C<Try::Tiny> CPAN
+distribution improves the safety of exception handling I<and> the syntax. It's
+easy to use:
 
 =begin programlisting
 
     use Try::Tiny;
 
     my $fh = try   { open_log_file( 'monkeytown.log' ) }
-             catch { ... };
+             catch { log_exception( "Something went wrong: '$_'" };
 
 =end programlisting
 
-Not only is the syntax somewhat nicer than the Perl 5 default, but the module
-handles all of those edge cases for you without your knowledge.
+C<try> replaces C<eval>. The optional C<catch> block executes only when C<try>
+catches an exception. C<catch> receives the caught exception as the topic
+variable C<$_>.
 
 =head2 Built-in Exceptions
 
@@ -205,11 +207,10 @@ Z<builtin_exceptions>
 
 X<exceptions; core>
 
-Perl 5 has several exceptional conditions you can catch with an C<eval> block.
-C<perldoc perldiag> lists them as "trappable fatal errors".  Most are syntax
-errors thrown during compilation.  Others are runtime errors.  Some of these
-may be worth catching; syntax errors rarely are.  The most interesting or
-likely exceptions occur for:
+Perl 5 itself throws several exceptional conditions. C<perldoc perldiag> lists
+several "trappable fatal errors". While some are syntax errors thrown during
+the compilation process, you can catch the others during runtime. The most
+interesting are:
 
 =over 4
 
@@ -229,6 +230,7 @@ likely exceptions occur for:
 
 =back
 
-If you have enabled fatal lexical warnings (L<registering_warnings>), you can
-catch the exceptions they throw.  The same goes for exceptions from C<autodie>
-(L<autodie>).
+X<C<autodie>>
+
+Of course you can also catch exceptions produced by C<autodie> (L<autodie>) and
+any lexical warnings promoted to exceptions (L<registering_warnings>).
diff --git a/sections/idioms.pod b/sections/idioms.pod
index 25604bc3..07af2441 100644
--- a/sections/idioms.pod
+++ b/sections/idioms.pod
@@ -304,6 +304,7 @@ users can run directly.  All you need to do is to discover I<how> Perl began to
 execute a piece of code.  For this, use C<caller>.
 
 X<builtins; C<caller>>
+X<call_stack>
 
 C<caller>'s single optional argument is the number of call frames which to
 report.  (A I<call frame> is the bookkeeping information which represents a
diff --git a/sections/pragmas.pod b/sections/pragmas.pod
index fe871230..852c2757 100644
--- a/sections/pragmas.pod
+++ b/sections/pragmas.pod
@@ -2,25 +2,23 @@
 
 Z<pragmas>
 
-Perl 5's extension mechanism is modules (L<modules>).  Most modules provide
-functions to call or they define classes (L<moose>), but some modules instead
-influence the behavior of the language itself.
-
 X<pragmas>
 X<modules; pragmas>
 
-A module which influences the behavior of the compiler is a I<pragma>.  By
+Most Perl 5 extensions are modules which provide new functions or define
+classes (L<moose>). Some modules instead influence the behavior of the language
+itself, such as C<strict> or C<warnings>. Such a module is a I<pragma>. By
 convention, pragmas have lower-case names to differentiate them from other
-modules.  You've heard of some before: C<strict> and C<warnings>, for example.
+modules.
 
 =head2 Pragmas and Scope
 
 X<pragmas; scope>
 
-A pragma works by exporting specific behavior or information into the enclosing
-static scope.  The scope of a pragma is the same as the scope of a lexical
-variable.  In a way, you can think of lexical variable declaration as a sort of
-pragma with funny syntax.  Pragma scope is clearer with an example:
+Pragmas work by exporting specific behavior or information into their caller
+scopes--lexical scopes. Just as declaring a lexical variable makes a symbol
+name available within a scope, using a pragma makes its behavior effective
+within that scope:
 
 =begin programlisting
 
@@ -37,15 +35,8 @@ pragma with funny syntax.  Pragma scope is clearer with an example:
 
 =end programlisting
 
-=begin sidebar
-
-A sufficiently motivated Perl guru could implement a poorly-behaved pragma
-which ignores scoping, but that would be unneighborly.
-
-=end sidebar
-
-Just as lexical declarations affect inner scopes, so do pragmas maintain their
-effects on inner scopes:
+Just as lexical declarations affect inner scopes, pragmas maintain their
+effects within inner scopes:
 
 =begin programlisting
 
@@ -64,9 +55,9 @@ effects on inner scopes:
 
 X<pragmas; enabling>
 
-Pragmas have the same usage mechanism as modules.  As with modules, you may
-specify the desired version number of the pragma and you may pass a list of
-arguments to the pragma to control its behavior at a finer level:
+C<use> a pragma as you would any other module. Pragmas take arguments, such as
+a minimum version number to use and a list of arguments to change the pragma's
+behavior:
 
 =begin programlisting
 
@@ -78,7 +69,8 @@ arguments to the pragma to control its behavior at a finer level:
 X<pragmas; disabling>
 X<builtins; C<no>>
 
-Within a scope you may disable all or part of a pragma with the C<no> builtin:
+Disable all or part of a pragma with the C<no> builtin. This also respects
+lexical scoping:
 
 =begin programlisting
 
@@ -103,47 +95,63 @@ X<pragmas; C<strict>>
 =over 4
 
 =item * the C<strict> pragma enables compiler checking of symbolic references,
-the use of barewords, and the declaration of variables
+bareword use, and variable declaration
 
 X<pragmas; C<warnings>>
 
 =item * the C<warnings> pragma enables optional warnings for deprecated,
-unintended, and awkward behaviors that are not I<necessarily> errors but may
-produce unwanted behaviors
+unintended, and awkward behaviors.
 
 X<pragmas; C<utf8>>
 
-=item * the C<utf8> pragma enables the use of the UTF-8 encoding of source code
+=item * the C<utf8> pragma forces the parser to interpret the source code with
+UTF-8 encoding
 
 X<pragmas; C<autodie>>
 
-=item * the C<autodie> pragma (new in 5.10.1) enables automatic error checking
-of system calls and builtins, reducing the need for manual error checking
+=item * the C<autodie> pragma enables automatic error checking of system calls
+and builtins
 
 X<pragmas; C<constant>>
 
 =item * the C<constant> pragma allows you to create compile-time constant
-values (though see C<Readonly> from the CPAN for an alternative)
+values (see the CPAN's C<Readonly> for an alternative)
 
 X<pragmas; C<vars>>
 
 =item * the C<vars> pragma allows you to declare package global variables, such
-as C<$VERSION> or those for exporting (L<exporting>) and manual OO
-(L<blessed_references>)
+as C<$VERSION> or C<@ISA> (L<blessed_references>)
 
 =back
 
-X<C<autobox>>
-X<C<perl5i>>
-
-Several useful pragmas exist on the CPAN as well.  Two worth exploring in
-detail are C<autobox>, which enables object-like behavior for Perl 5's core
-types (scalars, references, arrays, and hashes) and C<perl5i>, which combines
-and enables many experimental language extensions into a coherent whole.  These
-two pragmas may not belong yet in your production code without extensive
-testing and thoughtful consideration, but they demonstrate the power and
-utility of pragmas.
+X<magic variables; C<$^H>>
+X<pragmas; writing>
 
 Perl 5.10.0 added the ability to write your own lexical pragmas in pure Perl
-code.  C<perldoc perlpragma> explains how to do so, while the explanation of
-C<$^H> in C<perldoc perlvar> explains how the feature works.
+code. C<perldoc perlpragma> explains how to do so, while the explanation of
+C<$^H> in C<perldoc perlvar> explains how the feature works. The CPAN has begun
+to gather useful pragmas, including:
+
+X<CPAN; C<autobox>>
+X<CPAN; C<perl5i>>
+X<CPAN; C<autovivification>>
+X<CPAN; C<indirect>>
+
+=over 4
+
+=item * C<autobox> enables object-like behavior for Perl 5's core types
+(scalars, references, arrays, and hashes).
+
+=item * C<perl5i> combines and enables many experimental language extensions
+into a coherent whole.
+
+=item * C<autovivification> disables autovivification (L<autovivification>)
+
+=item * C<indirect> prevents the use of indirect invocation
+(L<indirect_objects>)
+
+=back
+
+These tools are not widely used yet. The latter two can help you write more
+correct code, while the former two are worth experimenting with in small
+projects. They represent what Perl 5 might be.
diff --git a/sections/style.pod b/sections/style.pod
index 1ad10944..17d5bec3 100644
--- a/sections/style.pod
+++ b/sections/style.pod
@@ -4,60 +4,56 @@ Z<style>
 
 X<maintainability>
 
-The easier your program is to understand and to modify, the better.  This is
-I<maintainability>.  Set aside your current program for six months, then try to
-fix a bug or add a feature.  The more maintainable the code, the less
-artificial complexity you will encounter making changes.
+I<Maintainability> is the nebulous measurement of the ease of understanding and
+modifying an existing program. Set aside some code for six months, then return
+to it anew. Maintainability measures the difficulty you face making changes.
 
-To write maintainable Perl you must:
+Maintainability is neither a syntactic concern nor a measurement of how a
+non-programmer might view your code. Assume a competent programmer who
+understands the nature of the problem the code must solve. What problems get in
+the way of fixing a bug or adding an enhancement correctly?
+
+The ability to write maintainable code comes from hard-won experience and
+comfort with idioms and techniques and the dominant style of the language. Yet
+even novices can improve the maintainability of their code by adhering to a few
+principles:
 
 =over 4
 
-=item * I<Remove duplication.>  Perl offers many opportunities to use
-abstraction to reduce and remove duplication.  Functions, objects, roles, and
-modules, for example, allow you to define models of the problem and your
-solution.
-
-The more duplication in your system, the more work it is to make a necessary
-change, and the more likely you will forget to make a change in every place
-necessary.  The less duplication in your system, the more likely you've found
-an effective design for your problem.  The best designs allow you to add
-features while removing code overall.
-
-=item * I<Name entities well.>  Everything you can name in your
-system--functions, classes, methods, variables, modules--can aid or hinder
-clarity.  The ease with which you can name these entities reveals your
-understanding of the problem and the cohesion of your design.  Your design
-tells a story, and every word you use effectively can help you remember that
-story when you must later maintain the code.
-
-=item * I<Avoid unnecessary cleverness.>  Novices sometimes mistake cleverness
-for concision.  Concise code avoids unnecessary complexity.  Clever code
-sometimes prefers its own cleverness to simplicity.  Perl offers many
-approaches to solve similar problems.  One form may be more readable to your
-team.  Another may be faster.  A third may be simpler.  Where possible,
-optimize for obviousness first.
-
-You can't always avoid the dark corners of Perl, and some problems require
-cleverness to solve effectively.  Only good taste and experience will help you
-evaluate the appropriate level of cleverness.  As a rule of thumb, if you're
-prouder of explaining your solution to your coworkers than you are of solving a
-problem, your code may have unnecessary complexity.
-
-If you I<do> need clever code, encapsulate it behind a simple interface and
-document your cleverness very well.
-
-=item * I<Embrace simplicity.>  Given two programs which solve the same
-problem, the simplest is almost always easier to maintain.  Simplicity doesn't
-require you to eschew advanced Perl knowledge, or to avoid using libraries, or
-to pound out hundreds of lines of procedural code.
-
-Simplicity means that you've solved the problem at hand effectively without
-adding anything you don't need.  This is no excuse to avoid error checking or
-verification or validation or security.  Instead it's a reminder to think about
-what's really important.  Sometimes you don't need frameworks, or objects, or
-complex data structures.  Sometimes you do.  Simplicity means knowing the
-difference.
+=item * I<Remove duplication.> Bugs lurk in sections of repeated and similar
+code--when you fix a bug on one section, did you fix it in others? When you
+update one section, did you update the others?
+
+Well designed systems have little duplication. They use functions, modules,
+objects, and roles to extract duplicate code into reusable components which
+accurately model the domain of the problem. The best designs allow you to add
+features by I<removing> code.
+
+=item * I<Name entities well.> Your code tells a story. Every named
+symbol--variables, functions, models, classes--allows you to clarify or
+obfuscate your intent. The ease of choosing names reveals your understanding of
+the problem and your design. Choose your names carefully.
+
+=item * I<Avoid unnecessary cleverness.> Concise code is good, when it reveals
+the intention of the code. Clever code hides your intent behind flashy tricks.
+Perl allows you to write the right code at the right time. Where possible,
+choose the most obvious solution. Experience, good taste, and knowing what
+really matters will guide you.
+
+Some problems require clever solutions. Encapsulate this code behind a simple
+interface and document your cleverness.
+
+=item * I<Embrace simplicity.> All else being equal, a simpler program is
+easier to maintain than its more complex workalike. Simplicity means knowing
+what's most important and doing just that.
+
+This is no excuse to avoid error checking or modularity or validation or
+security. Simple code can use advanced features. Simple code can use great
+piles of CPAN modules. Simple code may require work to understand. Yet simple
+code solves problems effectively, without unnecessary work.
+
+Sometimes you need powerful, robust code. Sometimes you need a one-liner.
+Simplicity means knowing the difference and building only what you need.
 
 =back
 
@@ -65,44 +61,38 @@ difference.
 
 X<idioms>
 
-Perl steals ideas from other languages as well as from the wild world outside
-of programming.  Perl tends to claim these ideas by making them Perlish.  To
-write Perl well, you must know how experienced Perl programmers write it.
+Perl borrows liberally from other languages. Perl lets you write the code you
+want to write. C programmers often write C-style Perl, just as Java programmers
+write Java-style Perl. Effective Perl programmers write Perlish Perl, embracing
+the language's idioms.
 
 =over 4
 
-=item * I<Understand community wisdom.>  The Perl community often debates
-techniques, sometimes fiercely.  Yet even these disagreements offer
-enlightenment on specific design tradeoffs and styles.  You know your specific
-needs, but CPAN authors, CPAN developers, your local Perl Mongers group, and
-other programmers have experience solving similar problems.  Talk to them.
-Read their public code.  Ask questions.  Learn from them and let them learn
-from you.
-
-=item * I<Follow community norms.>  The Perl community isn't always right,
-especially if your needs are very specific or unique, but it works continually
-to solve problems as broadly as possible.  Perl's testing and packaging tools
-work best when you organize your code as if you were to distribute it on the
-CPAN.  Adopt the standard approaches to writing, documenting, packaging,
-testing, and distributing your code, to take advantage of these tools.
-
-X<C<Perl::Critic>>
-X<C<Perl::Tidy>>
-X<C<CPAN::Mini>>
-
-Similarly, CPAN distributions such as C<Perl::Critic> and C<Perl::Tidy> and
-C<CPAN::Mini> can make your work simpler and easier.
-
-=item * I<Read code.>  Join in a mailing list such as the Perl Beginners list
-(U<http://learn.perl.org/faq/beginners.html>), browse PerlMonks
-(U<http://perlmonks.org/>), and otherwise immerse yourself in the Perl
-CommunityN<See U<http://www.perl.org/community.html> for more links.>.  You'll
-have plenty of opportunities to see how other people solve their problems, good
-and bad.  Learn from the good (it's often obvious) and the bad (to see what to
-avoid).
+=item * I<Understand community wisdom.> Perl programmers often host fierce
+debates over techniques. Perl programmers also often share their work, and not
+just on the CPAN. Pay attention, and gain enlightenment on the tradeoffs
+between various ideals and styles.
 
-Writing a few lines of code to solve a problem someone else posted is a great
-way to learn.
+CPAN developers, Perl Mongers, and mailing list participants have hard-won
+experience solving problems in myriad ways. Talk to them. Read their code. Ask
+questions. Learn from them and let them learn from you.
+
+X<CPAN; C<Perl::Critic>>
+X<CPAN; C<Perl::Tidy>>
+X<CPAN; C<CPAN::Mini>>
+
+=item * I<Follow community norms.> Perl is a community of toolsmiths. We solve
+broad problems, including code analysis (C<Perl::Critic>), reformatting
+(C<Perl::Tidy>), and private distribution systems (C<CPAN::Mini>). Take
+advantage of the CPAN infrastructure; follow the CPAN model of writing,
+documenting, packaging, testing, and distributing your code.
+
+=item * I<Read code.> Join a mailing list such as Perl Beginners
+(U<http://learn.perl.org/faq/beginners.html>), browse PerlMonks
+(U<http://perlmonks.org/>), and otherwise immerse yourself in the
+communityN<See U<http://www.perl.org/community.html>.>. Read code and try to
+write solutions--even if you never post them, this is a great opportunity to
+learn.
 
 =back
 
@@ -110,47 +100,36 @@ way to learn.
 
 X<efficacy>
 
-Knowing Perl's syntax and semantics is only the beginning.  You can only
-achieve good design if you follow habits to I<encourage> good design.
+Maintainability is ultimately a design concern. Good design comes from
+practicing good habits:
 
 =over 4
 
-=item * I<Write testable code.>  Perhaps the best way to ensure that you can
-maintain code is to write an effective test suite.  Writing test code well
-exercises the same design skills as designing programs well; never forget that
-test code is still code.  Even so, a good test suite will give you confidence
-that you can modify a program and not break existing behaviors you care about.
-
-=item * I<Modularize.>  Break your code into individual modules to enforce
-encapsulation and abstraction boundaries.  Make a habit of this and you'll
-recognize individual units of code which do too many things.  You'll identify
-multiple units that work too tightly together.
-
-Modularity also forces you to manage different levels of abstraction; you must
-consider how the entities of your system work together.  There's no better way
-to learn the value of abstraction than having to revise systems into effective
-abstractions.
-
-=item * I<Take advantage of the CPAN.>  The single best force multiplier for
-any Perl 5 program is the amazing library of reusable code available for anyone
-to use.  Thousands of developers have written tens of thousands of modules to
-solve more problems than you can imagine, and the CPAN only continues to grow.
-Community standards for documentation, for packaging, for installation, and for
-testing contribute to the quality of the code, and the CPAN's centrality in
-modern Perl has helped the Perl community grow in knowledge, in wisdom, and in
-efficacy.
-
-Whenever possible, search the CPAN first--and ask your fellow community
-members--for advice on solving your problems.  You may even report a bug, or
-submit a patch, or produce your own distribution on the CPAN.  Nothing
-demonstrates you're an effective Perl programmer more than helping other people
-solve their problems.
-
-=item * I<Establish sensible coding standards.>  Effective guidelines establish
-policies for error handling, security, encapsulation, API design, project
-layout, and other maintainability concerns.  Excellent guidelines evolve as you
-and your team understand each other and your projects better.  The goal of
-programming is to solve problems, and the goal of coding standards is to help
-you communicate your intentions clearly.
+=item * I<Write testable code.> Writing an effective test suite exercises the
+same design skills as writing effective code. Code is code. Good tests also
+give you the confidence to modify a program while keeping it running correctly.
+
+=item * I<Modularize.> Enforce encapsulation and abstraction boundaries. Find
+the right interfaces between components. Name things well and put them where
+they belong. Modularity forces you to reason about the abstractions in your
+programs to understand how everything fits together. Find the pieces that don't
+fit well. Improve your code until they do.
+
+=item * I<Follow sensible coding standards.> Effective guidelines govern error
+handling, security, encapsulation, API design, project layout, and other
+maintainability concerns. Excellent guidelines help developers communicate with
+each other with code. You solve problems. Speak clearly.
+
+=item * I<Exploit the CPAN.> Perl programmers solve problems. Then we share
+those solutions. Take advantage of this force multiplier. Search the CPAN first
+for a solution or partial solution to your problem. Invest your research time;
+it will pay off.
+
+If you find a bug, report it. Patch it, if possible. Fix a typo. As for a
+feature. Say "Thank you!" We are better together than we are separately. We are
+powerful and effective when we reuse code.
+
+When you're ready, when you solve a new problem, share it. Join us. We solve
+problems.
 
 =back