I keep lots of little checklists of to-do stuff. I used to keep them on a legal pad and I threw away the pages when they were done. Now I use an iPad app, so my history is always stored,but I don't save it in any form of official documentation.

I'm a programmer so most of my work is documented via version control, but there's lots of little fixes to non-version controlled software, database changes and check-ups I do as I fill a sort of support role as well.

We've been trying to document what we do in my department more so the idea came to me, but my changes aren't the ones that have been causing problems.

Should I keep my task list as a sort of official documentation? How would I make sure it's actually useful for someone other than me?

  • 1
    Why would database changes not be in source control? And why not check in scripts you use to do checkups?
    – HLGEM
    Commented Apr 13, 2012 at 18:55
  • @HLGEM I'm working on getting that started, but this isn't just about database stuff
    – Rarity
    Commented Apr 13, 2012 at 21:33

7 Answers 7


It sounds like your department is trying to keep better track of who is doing what and what is being done, so towards that end I would say yes, you should keep them. That said, it sounds like in the format they are in, they will not be useful to many other people, as they may be random collections of big and little tasks with little associated information or tags.

If there is a concerted effort in your department to track and document more, it does sound like a good time to begin using software for this. One of the huge benefits of using a service like Fogbugz, Teambox, Trello, Pivotal Tracker, etc, is that everything you do becomes searchable to both yourself and any current or future team members. Want to see the first time someone dealt with a particular issue, or if it comes up often? Search for it, and see what comes up.

Personally, I implemented Teambox in my workplace, and I encourage my coworkers to use it for collaborative tasks. But I also use it myself for things that only I need to keep track of, knowing that whoever is in my role in the future (even if it's me!) may appreciate this history of how certain things were handled before.

Many of these systems are fairly quick and easy to use and integrate a commenting stream do that updates and discussions around a task are stored with that task. Also, if there are repeatable task lists, many of these systems let you store them as a template.

  • Use a Ticketing System (Also called Issue Tracking: Such as Trello, Jira... etc).
    – Sandra K
    Commented May 29, 2018 at 14:24

I had kind of the same situation at my previous employer. I ended up just starting to write up in our wiki each time I had a new non-trivial support issue I had to deal with. It was somewhat enlightening, as there was a significant amount of information that I had just internalized. Even the tiny issues really assume that you have at least some level of institutional knowledge.

It's a pain to do when you start, but afterwards, it's kinda nice as you can take a vacation and maybe get one phone call instead of 3-4 a day. :)

  • That sounds like a lot more than a simple checklist. Commented Apr 13, 2012 at 17:24
  • I wish we had a Wiki, I sorta liked the idea of a wiki in a ticketing system. All we have are horribly sorted word documents
    – Rarity
    Commented Apr 13, 2012 at 18:55
  • @FrustratedWithFormsDesigner Yeah - my day-to-day stuff might be a checklist for me, but it's not going to be for someone else. They'll likely need the half page of background info to grok what's going on.
    – Brandon
    Commented Apr 13, 2012 at 21:25
  • @Rarity Set one up. Install IIS on the dev server, grab Windows Platform Installer and install ScrewTurn and just run with it. I prefer to ask for forgiveness than permission. :)
    – Brandon
    Commented Apr 13, 2012 at 21:26
  • 1
    @Rarity I'm a Windows .NET guy myself, so I defaulted to using the WPI, but I understand where you're coming from. Throw MediaWiki at an Apache box and go to town. :)
    – Brandon
    Commented Apr 13, 2012 at 22:00

I would say you should document everything you do. If the only documentation is the checklist then yes, it should be saved somehow.

A note on terminology though, I'm not talking about "documentation" in the sense of someone else referring to it later, I'm talking about a record of your activities, suitable for mentioning at your performance review. Keeping a list of what you've done will help you put together a statement of accomplishments, and if you've missed important goals it will give you an idea of what other tasks came up that made the goals/deadlines slip.


Maybe. I think the place they would be most useful would be training staff to take on new tasks that they are unfamiliar with. For example, trouble shooting a specific class of problems might involve walking through some steps and using a checklist to eliminate certain situations. A checklist might also be good for tasks such as complicated code deployments or server changes. I've seen simple checklists in the documentation for developer setup guides for setting up the environment for more complex projects.

The downside of a checklist is when the person following it is unknowingly on an instance of the task that deviates a bit from what the checklist assumes. Hopefully though, that won't happen until after the person is skilled enough to not need the checklist and make their own decisions.

You also want to avoid having people become entirely dependent on the checklist, so maybe don't make it too detailed - maybe write it more as a high-level guidline, unless the specific task will not change and the deep detail is necessary.

  • Unfortunately my checklists are more only for me, it'd take some substantial rewriting for them to be useful to others. especially as anything more than "what I did lately"
    – Rarity
    Commented Apr 13, 2012 at 16:24
  • @Rarity: Are they at least repeatable, such that you could use them again in the future to avoid having to figure out everything all over again? Commented Apr 13, 2012 at 16:26
  • Not as of yet, they're usually not split into sub-tasks. If something's actually complicated I put it out in an actual document, like how to install our server.
    – Rarity
    Commented Apr 13, 2012 at 16:28
  • @Rarity: Only useful to you, for non-repeatable tasks... Based on how you decribe them, I think you might get more use by filing your grocery shopping lists as documentation. At least those are sometimes repeatable. ;) Commented Apr 13, 2012 at 16:31

You should check your companies document retention policy. Some companies may require you retain them, some require that you do not. The reason is after a certain amount of time they can be considered discover-able documents for legal proceedings. These vary by company. I have worked at companies that considered any document over 5 years a record that required retention. Even if it was a menu used for take out that had a not scribbled on it.

From Wikipedia

The retention period of a document is an aspect of records management. It represents the period of time a document should be kept or "retained" both electronically and in paper format. At the termination of the retention period, the document is usually destroyed. The term is generally used by accountants and tax professionals whose occupation involves dealing with legal documents that only need to remain in existence for a certain amount of time. The retention period varies for different types of records. For example, business incorporation documents have a permanent retention period (meaning that they should be retained and never be destroyed), but receipts for tax-deductible purchases by an individual taxpayer usually have a three-year retention period (and can often be safely discarded after that point.) The length of the retention period vary by industry and are based on the likelihood that the document will be needed at some point in the future for ligitation reasons. Records that will serve no further purpose (as determined by the length of their retention period) are destroyed for space issues, usually by paper shredders.


To answer your last question first, you will only know if other people are interested after you document it somewhere others can see it.

My suggestion: document it on a wiki where everyone can see it. You can either put it on a page as an "official" procedure for your position or on a personal page. But then at least other people can see it when you are away and take over your tasks. And people in similiar positions across the company can peer review it and exchange ideas.

The key is keeping it public and easy to update (and access, even via your iPad).


Do you have a case tracking system like Bugzilla or FogBugz? I work on a programming team and we use our FogBugz instances for general tasks in addition to bugs/feature requests and it works pretty well.

  • IT's a small system and practically a one man team for any given fix, so we don't use a bug tracker, just commit messages. Hasn't been a big enough problem to get anyone else to use a bug tracker.
    – Rarity
    Commented Apr 13, 2012 at 18:48
  • Actually you may be in luck then. FogBugz (and probably others) will let you use the hosted version of their tool free if you have less than 2 users (fogcreek.com/fogbugz/StudentAndStartup.html)
    – JohnFx
    Commented Apr 13, 2012 at 18:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .