Sometimes it seems as if there are two kinds of working programmers. The first kind clocks in at 9 am, puts in a day of work, and then goes home and doesn't think about programming. That's all well and good—some days I don't want to think about my work outside of working hours.
The second kind of programmer puts in a day of work, then practices more programming (hopefully not work) outside of work, whether reading books or essays, attending user group meetings, or contributing to free software projects.
These are stereotypes and generalizations and two foci of an ellipse which contains all working programmers, but they're useful as far as they conform to accuracy.
The danger of the second type of programming is burnout. I find that I'm a much better designer/developer/documenter when I have a range of interests and activities which help me rest and rejuvenate and widen and improve my perspective.
The danger of the first type of programming is a hyperfocus on a specific domain and very specific techniques within that domain. (You can see this with Google. When every product or service must fit within a highly scalable, highly available, big data, huge support framework which absolutely must produce single-identity, Internet-scale tracking of users and their activities, you get a bunch of mediocre products held together by the desire to sell eyeballs rather than help users solve problems.)
The first group might benefit the most from sharpening the saw.
I've helped companies improve their design and scheduling and problem solving skills by working through exercises unrelated (and partially related) to their work during brown bag sessions at lunch. I've rarely heard of companies which encouraged programming challenges or exercises at lunch or on Friday afternoons or whenever.
(With that said, Google deserves a lot of credit for Testing on the Toilet — while it demonstrates design flaws of Java more often than you might imagine, it's a creative approach to solving institutional problems.)
How does your company encourage developers to improve their skills? Is there a systemic approach? Is there training? Are there books?
Full disclosure: I'm interested in getting books like Modern Perl read more widely, and if it takes producing questions or exercises suitable for brown bag sessions, I'm interested.
I think it would be great to have questions/challenges/exercises added to Modern Perl. Over the last few months I've been teaching a weekly seminar on Perl 5.12 to a number of developers in the office. We've used the Learning Perl and Intermediate Perl books primarily, supplementing from Perl core docs. When I started the series my hope was to steer people consistently toward style and idioms recommended in Modern Perl, and I think overall that goal has been met. However, now that there's a basic foundation for at least a handful of people, it might be time to start a seminar series particularly focused on those patterns and practices, and having the additional material in the book would be very useful indeed in such an effort.