Documenting one’s research data and methods often feels more like winning a battle against inertia than learning new tricks to documentation. After all, don’t we all know that we should be recording how and why we did things…it is just a question of finding time to do it?

This may be true, but it is also helpful to consider that documenting data efficiently is really the key. Once we set up a system that enables effective documentation, contributing to it should require far less effort and it should ideally make it easier to continue documenting as the project progresses: in other words, a lot of initial effort followed by inertia in favor of documentation rather than against it. After all, once a workflow is in place for documenting, that system can be replicated across many projects, reducing the work the next time around.

Moreover, since we don’t want to take shortcuts in documentation comprehensiveness, we need to take advantage of every time saver available. Make use of the codebook-making function in SPSS, for example (select Analyze > Reports > Codebook from your menu); use automatic TEI-XML global element generators like this one from the University of Rochester; when documenting computer code through commenting, read through style guides like this one for Python and implement its recommendations as you go so that it becomes second-nature; and don’t be hesitant to grab templates like this one from Cornell University for readme files. Data documenting is a social experience (you want others to immediately comprehend your codebook), not an exercise in authoring unique gems that only you can decipher–so templates are great.

Lastly, make sure your documentation is going to last as long as your data. It does no good to go through all the trouble of building a nice software-agnostic, cross-platform readable file only to provide documentation that no hardware will be able to read in five years. Use helpful formats like pdf, txt, and even html that have staying power!