The times that I have been best about documenting things, and building the habits to do so, are when I am documenting myself out of a part of a job that I don't want to have to do anymore. I think that "make the new guy write docs" doesn't work because the new guy doesn't know the answers. He needs the docs to be written for him.
I'd start by focusing on alleviating pain. Figure out where you have the most natural incentive to document stuff, and focus there first. Do a little analysis on your request queue, and see what your top 10 most frequent requests are, and make sure the process for handling is documented to the point where anyone on your team can complete them successfully. Then make sure that junior staff only bump stuff up to senior staff if it's not in the top 10. This will give senior staff more time to solve the sticky problems, or perhaps write more documentation. -- Christopher Manly Network Software Engineer Cornell Information Technologies NCS Network Engineering [email protected]<mailto:[email protected]> 607-255-3344 On Mar 1, 2010, at 7:56 PM, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> wrote: So, I suspect like at least a few of you, I suck at documenting what I've done. Unless I make a conscious effort to do it as I go along, it often doesn't get, as the next fire takes priority. One thing we've implemented recently at work is a documentation queue in our ticketing system. The idea being that if someone is looking for information and can't find it on our internal documentation site, they can drop in a ticket and the person responsible for that system/service/whatever should get the appropriate docs written. This (maybe) solves the problem of forgotten/overlooked documentation. But what about keeping up with documentation as tasks are accomplished, new systems are stood up, etc? What tips do folks have for getting better at documenting in their daily tasks? There are definitely procedural things we could do to improve this, and we should probably be doing those, e.g., no system goes into production without full and proper documentation. But we're not there yet, and sometimes the nature of $WORK necessitates deploying things before we're fully ready. That's a political issue, and has to be overcome in other ways. So I guess what maybe I'm looking for is tips to help me improve outside of the procedural/operational framework. Things like "spend the first 15 minutes of every day documenting what you did the previous day" or "make the n00b on the team do all the documentation." OK, so maybe that 2nd one is just wishful thinking :) -josh _______________________________________________ Discuss mailing list [email protected]<mailto:[email protected]> http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
_______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
