Placing Our Stuff So We Can Find It Later: A Meta-Learning Essential

Abstract: Learning from our previous work is often inhibited by difficulties in finding relevant materials after a period of time and, when found, making sense of them. Presented here are several practical approaches for alleviating this difficulty. The suggestions are (1) craft meaningful, contextual file names; (2) place things where they can be easily found; and, (3) relentlessly discard useless items.

It is widely accepted that meta-learning is a matter of acquiring skills. This paper suggests how three specific skills related to using computing technology can be improved, thus enabling enhanced learning for these populations. Following this discussion, the paper will link back up with a meta-learning perspective on the value of improving these skills.

Knowledge workers seek information in order to produce information. One meta-learning aspect of being efficient at producing information assets is being able to find related materials in both the short- and long-term. In work environments, information assets that were crafted previously could often contribute to a task at hand: If only the right things could be found at the right time.

While it is valuable to learn from mistakes, it is wiser to learn from success. By being able to access our previous work, we foster opportunities to learn from our experiences and subsequently produce improved assets. By being cognizant of how we produce information, subsequent seeking by future readers can be more fruitful, especially when it's our own work group.

This article advocates engaging in a few seconds of forethought when naming and storing files, and relentlessly disposing of trash. It takes a minute now; saves hours later. This advocacy derives from decades of the author's experience managing teams chartered to produce myriad information assets Ð- articles and presentations, media programs, research analysis and reports, and software applications. The typical challenge wasn't accomplishing the work at hand because the staffs were always highly competent, but instead establishing ways of working together in an effective manner such that the work product, and its inevitable spin-offs, could be made readily available at some subsequent time.

The recurring observation is that teams often start work from scratch because earlier work is unknown, or if discovered, is too hard to decipher. Viewed differently, users often don't know today what they knew yesterday, mainly because they manage their information assets in a way that does not necessarily lead to easy recognition and recall at some future time. Instead of remembering, or being able to quickly find related materials, projects often commence tabularasa. For collaboration amongst people, especially as personnel change and tasks morph, the manner in which items are named and stored can greatly impact group performance, especially when a task today could benefit from acquiring some fragments of a work done a while ago.

The underlying premise here is that the clerical tasks associated with producing information assets is drudgery, and ignored as often as possible by most people. Moreover, there tends to be a sense of excitement - of immediacy - in starting a new project. People want to "get on with it" and not sift through sundry files stored every which where. Consequently, not much learning is evident when the general mode of initiating production is tabularasa.

Anecdotal observations suggest that computer users can learn to improve their skills in a minimal amount of time. Yet, because many are self-taught, they often have approaches that are less than optimal and not conducive to collaborating effectively with others. By adopting a few simple rules numerous problems can be obviated long before they might occur. Moreover, it enables work done today to better contribute to work to be done tomorrow.

Individuals devise myriad approaches for storing and archiving materials. Such methods, however, are often idiosyncratic and become unworkable once it becomes necessary to collaborate. What works for "me" rarely works for "us." Familiarity, and at times the politics of hierarchy, can fashion how information assets are named and stored, typically without a second thought to making things easy for subsequent usage. Several common sense rules can greatly simplify handling information assets, and make them more valuable in the future when they can be used either as part of producing new information, or as reference material.

People are often pack rats with information, especially computer files. We excel at storing things, perhaps even hoarding them; yet finding the information we seek at some future time can frequently become a tedious challenge. Why? The reasons are myriad, but poorly chosen file names, scattered storage locations, and keeping too many trash files in the mix, is each a significant contributor to the frustrations. Once the information has been created and stored, often it's as good as gone from future utility. One practical approach is to keep things simple, and in context, from the outset of a project.

Things To Do
Consider an analogy to a flock of birds turning together in flight. This beautiful feat of coordination and cooperation can be modeled with just three simple rules [see note 1]. Likewise, collaborators can work much better together -- and be prepared for the better performance in the future -- by just adopting three simple rules when creating their information assets:

Craft meaningful file names that don't become opaque after a short while;
Place items in easy to identify and scan locations;
Prune clutter relentlessly.
Craft Meaningful Filenames
Use file names that are simple yet informative enough that when looked back upon a year later, they have some real meaning: Not too long, nor too short. Remember that the file has its own attributes such as the date. Also, keep filenames clear of lettering that states the obvious (e.g., no need to spell out "version" when any reader would recognize it as a version. If the files are related to a project, use enough of the project name that it's easy to recognize it later. File suffixes can often indicate the type of file, but not everyone has their computers set to display these so that may be useless.

Below is an example related to the exciting new Gizmo project for the wonderful Pluto Partners.

Item
Good Example
Bad Example

Proposal v1
Pluto_proposal-v1
Proposal1

Final Proposal
Pluto_proposal_final
Plufinal.doc

Presentation draft #3
Gizmo_preso-v3
Giz-version3-7jan04

Gizmo final specs
Gizmo-specs-final.xls
Pluto gizmo project specifications final.xls

Hint: Using underscores and hyphens instead of spaces in the name makes it easier to eventually post these files to the Internet or a company's intranet, making the materials more available for a broader audience.

In each case in the above table, a name was crafted that was neither too long nor too short. Each is informative, will sort well, and require no additional information to know what it was and what it was about. Keep this simple by naming the file in terms of:

what it is related to -e.g., "pluto" or "gizmo";
what type of material it contains -e.g., proposal, preso, brainstorm; and,
what the "state" is -- e.g., "final," "v3," or "rough."
These three bits of information provide context that enables a reader to immediately recognize the project, the type of asset, and its state. This will be highly useful data once short-term memory about the project fades. A rule of thumb is to avoid naming a file as "final" until it is. When a file is finished, just change the name of the most recent version to "final" It's not a good idea to have any drafts of files named "final"

Place Files Where They Can Be Easily Found
As a general approach, place files where they can be found now and located later. With the familiar metaphor of folders and files: Is it better to have just one folder and put all the files under it? Sometimes. Is it better to have an elaborate hierarchy of sub-directors broken down to highly-detailed granular levels. Sometimes. But what's best is to organize folders such that there aren't too many, nor too few - neither too deep or too shallow. This means striking a workable balance between how "perfect" or "accurate" the categories of the subfolders are, vs. how easily people can use them, including going back and finding things later. One observation is to add structure and new subfolders later rather than earlier. The human brain is highly adept at scanning lists and noticing what's relevant, and the clerical tasks of always placing or finding files inside deep hierarchy can be irksome. Bet on the brain to make sense instead of the hands to always have to be clicking and moving files.

Some suggestions (using meaningful naming for folders as well):

Have a top folder name designating the project (e.g., Gizmo) [see note 2];
Maintain as few sub-folders as needed - every time a folder gets perhaps one or two dozen entries, subdivide what make sense (e.g., perhaps by types -- presentations, code, brainstorms proposals, spreadsheets), and dispose of whatever isn't absolutely critical
Keep a subfolder in each project for old and inactive materials: e.g., drafts, brainstorming notes, previous manuscript versions or various component files, etc., and be vigilant about moving files into it that haven't been used in a few days or so
For a team, common repositories are the best idea: e.g., intranet, shared drives, network storage, collaboration spaces, etc. [see note 3]. Avoid email attachments whenever possible when working with others on a project. Use them only as a last resort. Such practices may seem convenient at first but inevitably lead to a plethora of related versioned files, spread across the mailboxes of numerous team members, each of whom typically has an idiosyncratic means of handling assets. Without a centralized repository, when a project is done files that may be important to future readers are likely distributed every which where making it difficult to establish a common archive.

Prune Clutter Relentlessly
Sooner or later a project, or a major project phase of it, becomes history. One extremely valuable activity is to go through the files, keeping only those that are absolutely essential - not those that that "might be needed someday." (They most likely won't be.) This necessary task is easy if the clutter is pruned on a regular basis. There's no need to hold on to multiple copies of file drafts - perhaps the first one, and one or two in between with valuable client edits or suggestions, but not too many. This clutter, when faced at some future time, can create an overwhelming clerical task of sifting through it, which means the materials won't get used - and tabularasa will result. It's better to not encounter this situation at all. Prune clutter relentlessly.

Things Not To Do
Earlier was a list of three simple rules that could foster better long term learning in the crafting information assets. Here is a companion list of things NOT to do.

Don't establish a broad over-arching policy on naming and storage (i.e., trust the group to pick good names)
Don't expect large-scale content management systems to suddenly solve all the problems;
Don't sit and argue about the naming and storing conventions, unless it is to make them drastically easier to use.
Avoid Comprehensive Naming Policies
The problems with establishing a broad overarching policy on naming and storage are uncountable. What's important is that a work team finds a simple way of working together where the production of the information assets is the objective, not creating the most elegant naming convention. The latter is nigh impossible because things do change, and a broad policy will rarely fit. This means that much of the time that was spent on crafting elaborate naming policies, in the end, will have been wasted [see note 4]. In a work group, come up with straightforward names Ð quickly -- and stick to them.

Avoid Large Scale Content Management Systems
Unless an organization is faced with needing to track and maintain a repository of large numbers documents (e.g., many hundreds or more) or for legal or regulatory purposes, a content management system can often be pricey overkill. Of course, in specific cases such systems are valuable and necessary, but for many work groups, what's needed is just an agreed upon set of names and locations as to where to store things, for the current project [see note 5]. All too often, a complex content management system can become an extra set of clerical tasks that people must learn and it can tend to focus people's attention on "what they are working with, instead of what they are working on." [see note 6]. It's better that their effort be focused on the work product, not the technology supporting the work.

Avoid Quibbling Over Name/Location Fine Points
It's all too common for work teams to become entrapped in useless quibbles about issues such as names [see note 7]. What's most important is to have a simple approach that works "good enough." Although the naming approach for a project is of course imperfect, such situations can become a convenient opportunity for some people to focus more on their rhetorical proclivities than finishing the task at hand. For the manager, pick an approach and stick with it for the project's duration. Wait for the next project to upgrade the approach. Show leadership. Keep the main thing, the main thing [see note 8].

Wrapping Up A Project or Phase
Projects have natural breakpoints. These may be driven by dates (e.g., a paper deadline, executive council presentation schedule, etc.) or by resources (e.g., budget expires, personnel departing, etc.). Before moving on to the next project (or even the next phase), go through the project folders and discard as many items as feasible (i.e., choose to discard more than less). Write a brief note about the folder's contents and put it in the top-level project folder. If possible, archive them together, using a meaningful name (e.g., gizmo_phase1_archive) [see note 9]. Put copies in safe places, and discard all the single files and folders.

Ties With Meta-Learning
We've observed that the skills advocated above can aid individuals on a work team to become more efficient. More importantly, the team itself can become noticeably more productive, especially in terms of learning from its past work and being able to incorporate past work product into current activities. Taken together, these skills address how to better use some basic tools of knowledge workers. As such, the general notions of "how to name" and "where to place" materials supercede any particular instance of technology. Technologies can readily change, but a mindset of effective naming and placing can transcend any particular technology, application, or program.

Naturally, the three skill refinements mentioned in this article are but a small selection of the many relevant ones in a broad suite of information production skills. As information technology continues its relentless advance, especially as it becomes more and more of an expected infrastructure wherever people work, it will become progressively more important that people refine their learning to concentrate on what they're working "on" instead of "with." Whereas new computer programs will continue to appear, and older ones will continue to have numerous enhancements, it is important that people not focus on the software they're using, but on how to effectively complete the task they've undertaken. Notions about "how to use a database" are much less perishable than skills of "how to use Gizmo Database 2.1."

While there is a fine line between mastering a tool and mastering the process of using a tool, with information technology it's somewhat more important to focus on general principles instead of specific elements of how a particular instance of software operates, because the latter changes regularly. The more refined understanding a person has of general principles about how to use certain classes of tools (e.g., spreadsheets, code editors, databases, word processing, etc.), the faster learning of new and upgraded software can occur, and the greater their productivity will become for them and their teams.

Summary
This practical approach is advocated a method to aid subsequent learning, especially in regard to team members learning from their previous work when crafting information assets. Several suggestions are presented describing: (1) meaningful file names; (2) simple organization of storage; and (3) pruning clutter. By keeping a concise note in the main folder about the general contents of the archive, people can find things later. Also, computer-aided tools for search and retrieval can be brought to the task when appropriate.

Notes:

The three rules deal with (1) separation; (2) alignment; and, (3) cohesion. See Reynolds, Craig. (1995) "Boids." http://www.red3d.com/cwr/boids. Also see: http://www.brunel.ac.uk/depts/AI/alife/al-boids.htm
Organize things in terms of what's most important to the task at hand - perhaps the top folder is best the name of a project, the name of a client, or some such. Just be consistent.
These may be network-based such as shared public folders, an organization's intranet, or various commercial products/services that provide for this such as SharePoint or eRoom.
Naturally, in some instances in certain organizations comprehensive naming conventions are necessary. Groups focused on tracking legal cases, investor relations, tracking drug trials, and the like certainly need highly formalized procedures. But that is not the target of this article. Here, the focus is on the small workgroup in their preparation of materials, often long before they become formalized.
Content Management Systems come in all sizes and flavors. This article is not critical of their significant capabilities or contributions, but the fact remains that in many work groups, such a system is costly to set up and maintain, for some users can be daunting, and puts more focus on the tools than the products of the tools. Two notable CMSs are the Open Source one known as Plone (http://www.plone.org) and the commercial product offered by Documentum (http://www.documentum.com). Both are exceptionally powerful approaches for content management. Whether such a system provides a reasonable cost/benefit for any particular usage is best carefully reviewed on a case by case basis.
Distinguising between "working with" and "working on" was a remark made by Terry Winograd at the IBM Almaden "New Paradigms Using Computers" Annual Conference, 2001.
For a disheartening exposition of how complex naming and its associated staff quibbles can undermine effective organizational performance, see "The Curse of Xanadu," Wired June 1995. http://www.wired.com/wired/archive/3.06/xanadu_pr.html
Jim Barksdale, CEO of Netscape Communications, guiding message to employees: "The main thing is to keep the main thing, the main thing." 1995.
Pick your preferred tool. Some familiar ones are tar, stuffit, winzip.
Jamie Dinkelacker, Ph.D.
The Sunarcher Organization
Los Altos, CA, USA
http://sunarcher.org/jamie