The CodePlex team has a Slack time policy, and it’s worked out very well for them.
- Jim Newkirk and myself used it to work on the xUnit.net project.
- Jonathan Wanagel used it to work on SvnBridge.
- Scott Densmore and myself used it to work on an ObjectBuilder 2.0 prototype.
For others, it was a great time to explore things that were technically not on the schedule, but could eventually end up being of great use to the rest of the team. I’m so convinced of the value of this that if I’m ever running a team again, I’m going to make it part of the team culture.
Have you had a formalized Slack policy on your team? How did it work out?
Edited: I just realized I didn’t define Slack. For those who haven’t read the book, Slack is what Google’s ‘20% time’ is: you’re given some slice of your day/week/month/year on which to work on things that are not necessarily directly related to your day-to-day job, but might have an indirect benefit (obviously if you work on stuff that’s totally not useful for your job or your company, your manager probably won’t think very well of the way you spent the time :-p).
I just want to mention Google’s policy on the subject.
20% of the day should be used for private projects and research.
I think it is time for managers to face the fact that most good developers are a bit lazy. If they weren’t, we wouldn’t have concepts like code reuse.
If this laziness can be focused into a creative force, and the developers can read up on technical issues and experiment with architecture and language features, I am certain that the end result will be better code and a more satisfied developer.
So, if you are a manager: Let your developers slack of now and then. Encourage them to hold small seminars with the team to discuss new ways of doing stuff.
If you are a developer: Read, learn and love your craft. You have one of the best jobs in the world, as long as you are willing to put some time into learning the best ways to do your job.