ÂÜÀòÉç¹ÙÍø

Very few people in our field – not our beloved coauthors; PhD students; P&T Committee Chairpersons; that one guy who never shuts up at meetings – seem to be efficient in the ways of using a computer. With the primary goal of making you more efficient, and a secondary goal of avoiding looking at some really painful reviewer comments this afternoon, I present you with some rules to make you more efficient working with computers.

What’s in a Name?

Give each project a short but descriptive name of one or two words. Avoid generic names like "project", "research", "revision", or "paper". Make it distinguishable from your other work yet short enough that you won’t go deranged after typing it the first 100 times. If the project is the only one you are doing on "Music Marketing" call it "music". Get the author team to buy in to the name.

Create a folder with that name. Many users keep their files in a single giant, flat space, often on the desktop. The Creator created folders for a reason. Use them.

Think about whether your project folder should go on your desktop or under your main Documents folder. The desktop should be reserved for impending or current tasks and be used as a reminder of what is going on now. As such you should note that clutter kills. On the other hand your Documents folder is ideal for storing permanent information and should contain a larger number of files. Whichever you pick, be sure to use a new folder for a new project. Did I mention folders?

Now use the name you chose as the beginning of all file names associated with the project.

For every file you create (always within the project folder), add a version number after the project name. A simple strategy is to use yyyy_mm_dd so your versions will sort by age from old to new. Make sure you use 01, 02 with leading zeros for days and months less than 10 to maintain correct sort order. If you don’t like underbars, use a dash, a space or cram things together. Or use an underbar between the project name and the date, and then dashes within the date. Whatever. Pick a rule and follow it. Files should neatly line up in a helpful order when you list them. That’s how you find stuff.

All supplementary files should follow the same naming convention with an additional name: music_author-page_2018_04_20.docx. Data and code should likewise include a layer on what the code does or what the data are: music_hazard-models_2018_04_20.R, say, or music_data-cleaned_2018_04_20.dat.

You might not want to literally create a new version (name) every time you save something, but that is the ideal. Save early and save often and keep updating the name. Disk space is cheap so use it to keep your life drama-free ("Where did the third paragraph go? DANG*!&@#@!$!*@"). If you save more than one version per day, use a, b, c, …, immediately after the date or use the time.

Add your initials to the end of the file name for any file that more than one person will be working on. So a file might be called music_2018_04_20_ch.docx, although for most readers the "ch" would apply only if you changed your name to Cheese Head. In any event, versions can then be easily tied to the individuals who produced them.

Worried you will forget to change names? Copy before editing. Rename the new copy with its new version number and edit that version. It’s especially important that you establish a new version when you are handed a file from a coauthor to modify, or, when you attempt major surgery on a paper after a third glass of wine. Not that I would know.

Within your main project folder create a folder named "archive" where you will put old versions and other stuff no longer of prime importance. Keep the highest level of your project folder as clean as possible with only the files you are working on day to day. You could also have separate subfolders for data, code, IRB stuff, graphs, etc. Don’t be afraid to have sub-subfolders. You’re an academic; your mind can handle a deep folder hierarchy; and deeper structures are better for finding things than flat, wide file spaces once you hit a certain number of files. But experiment to see what works best for you. Yes, experiment. Never be afraid to spend an hour making yourself a half-hour more efficient on the computer.

You might prefer to put data and code in a folder underneath the folder pertaining to your stat program, but keep the naming consistent. You can link (on Windows create a "shortcut", on Mac OS an "alias") from one location to the other if you prefer to split things up.

Your project directory should be AESTHETICALLY PLEASING when looked at with File Explorer (Windows) or Finder (Mac OS) and should effortlessly remind you of what you were doing before you got called off to – oh horrors – teach. By the way, File Explorer/Finder should be as familiar to you as performance reports. The Creator also created those for a reason. Of course, here I mean File Explorer/Finder, not performance reports. No one really knows why the Creator created performance reports.

Coordination Among Coauthors

Take Track Changes seriously. Make sure the changes being tracked match the current state of agreement among the authors. When the team has agreed, accept changes rather than let changes accumulate indefinitely. In general the team should have a lively, continuous discussion (OK maybe the discussion might not rise to the level of lively) on Track Changes and how you want to use it. Talk to each other about process.

Be wary of stepping on other people’s changes, especially when coordinating by email. What this means is that if two authors are both working on a file separately and simultaneously, and both submit changed versions to a third author, an ugly scene may ensue. Like bad ugly. Without a sophisticated content management system, and here I pointedly add that Track Changes is definitely NOT one of those, changes have to be done sequentially. Think in terms of a "magic token". One at a time, each coauthor must claim said token. Only the person with the magic token can change the document. That person then copies the document back to the group and passes the token to the next author tasked with making changes.

If you would prefer to manage digital content in a less silly way, contemplate learning GitHub and persuading your coauthors to use it. Good luck with that, but if you use shared disk space to collaborate note that Microsoft Office has some ability to avoid problems. It, and competing products like Google Docs, will generally complain if two or more co-authors try to make changes at the same time.

The Five Rules of Backup

Just like we all have five fingers, there are five key backup takeaways:

1. Back it up. Do it don’t eschew it.
2. Never have fewer than three copies of anything you can’t afford to lose.
3. A backup copy on the same hard drive DOES NOT COUNT towards the three.
4. Two of the three copies should be at least 100 kilometers apart.
5. There is no fifth takeaway but I really wanted to have it be five.

A network attached storage (NAS) device is a great place to store one of the three copies. Remember, you are a professional knowledge worker. Buy an NAS to keep the knowledge you work on safe. Just Google "NAS backup". Better units will use RAID, which means that even if you accidentally drop the thing off a third story balcony, there is still a decent chance you will be able to get at your files. Compliment that with a third copy on free cloud storage from Google Drive, Microsoft OneDrive, Dropbox or Box. If your raw data are not anonymized, use a free encryption program to keep them safe before copying to the cloud (you know what I am going to say: just Google "free encryption programs").

To summarize do not I repeat do not let me catch you with 482 files on your desktop all named "RAWDATA".

---