Do you solicit and attempt to meet your employees' workstyle preference? Specifically, can those who benefit from or require a quiet work environment get one? (This is not anti-collaboration; it is simply anti-noise and physical distraction.)
As an admittedly anecdotal perspective, the majority of the best developers I've worked with have expressed a strong desire for this -- even as and because we have struggled with cubification, shrinking cubes, and other management "best practices".
A side-product of this was finding/accessing them online in the evening, after they'd driven home, had dinner, and ensconced themselves to achieve some real focus.
Specs (do you write down how stuff works? ... how to troubleshoot at 3 AM?) would be a good addition. It's a good list, though I don't see it becoming any more or less relevant when using Perl.
There doesn't seem to be anything specific to a "Perl Shop" on the list.
Perl specific maturity items would be:
1) Do all packages have documentation (pod) stored in the package file(s), and is it up to date?
2) Are there tests built using TAP (e.g. Test::More), and is this built into some kind of continuous build/test server?
3) Have a set of perlcritic rules been set up for the shop? Are these checked as part of code-review or scm check-in?
4) Is there a consistent set of rules for how external packages are brought into the current build? How are local changes to CPAN-originated packages handled?
These are the kinds of policies I'd expect to see implemented in a mature Perl Shop. The policies listed in the original post are those which I'd expect to see implemented in a mature software firm.
3 comments
[ 3.0 ms ] story [ 18.8 ms ] threadAs an admittedly anecdotal perspective, the majority of the best developers I've worked with have expressed a strong desire for this -- even as and because we have struggled with cubification, shrinking cubes, and other management "best practices".
A side-product of this was finding/accessing them online in the evening, after they'd driven home, had dinner, and ensconced themselves to achieve some real focus.
Perl specific maturity items would be:
1) Do all packages have documentation (pod) stored in the package file(s), and is it up to date?
2) Are there tests built using TAP (e.g. Test::More), and is this built into some kind of continuous build/test server?
3) Have a set of perlcritic rules been set up for the shop? Are these checked as part of code-review or scm check-in?
4) Is there a consistent set of rules for how external packages are brought into the current build? How are local changes to CPAN-originated packages handled?
These are the kinds of policies I'd expect to see implemented in a mature Perl Shop. The policies listed in the original post are those which I'd expect to see implemented in a mature software firm.