[This post originally appeared at ProfHacker.]

One of the occupational hazards of being the kind of person who writes for or reads ProfHacker is the constant urge to try out new tools or techniques in the relentless search for “productivity.” Sharpening one’s tools might be a mark of a professional, yet constantly switching tools is the mark of someone who is just wasting time. As Jason has explained, ProfHacker is not interested in hacks for hacks’ sake.

Abraham Lincoln (almost certainly never) said, “Give me six hours to chop down a tree, and I’ll spend the first four sharpening my ax.” Whoever came up with it, that bit of folksy wisdom neatly captures an ambiguity about work. You’d be a fool to work with a dull ax, but being shrewd about your preparations can quickly turn into being lazy about actually doing your work.

How can you make prudent choices about which tools to use? I’d like to offer a few rules of thumb that I’ve developed for myself. I’ve thought about these in terms of what software to use, but I think they work for picking any kind of tool or settling on any kind of process. They’re listed in descending order of importance. I’m willing to stand by the first as an iron law of productivity; the rest have a lot more wiggle room.

1. The best possible tool is the one you’re already using to get work done. No, really. Are turning out a book a year using Microsoft Word 3.1 on Windows 95? Don’t worry about your technology, you’re doing just fine. Here is a story about John McPhee, where he describes how he uses a text editor barely updated since the 1980s. Are you barely getting any writing accomplished? Then your problem is definitely not your word processor, and you don’t have time to try out a new one. You can be sure that you will badly misjudge the costs of switching tools or work processes. After working with a tool for a while, you forget all the familiarity you’ve built up, all the muscle memory, all the ways that the tool is useful to you. Instead, all you see are the annoyances. But on the other hand, all you see about a new tool are the shiny new features, and you can’t see all the hours and days you’ll spend learning and adapting, fiddling and breaking the new tool.

2. Prefer the tool that your local co-workers use. Objectively speaking, Google Docs is probably better than Microsoft Sharepoint, and R is probably better than SAS. It’s probably a toss-up between Ruby and Python. But if all the people you work with use Sharepoint, SAS, and Python, then those are the tools you should be using too. Not only will you reap the benefits of easier collaboration, you’ll also gain access to a wealth of human expertise.

**3. Prefer the tool that is used by awesome developers. **You want to be using tools that the very best people are working, because they’ll sharpen your tools for you. For example, I use Vim to edit text because hundreds of developers have made plugins that solve almost all of my problems with editing prose and code.  I probably wouldn’t know how to use R except Hadley Wickham has created  many useful packages for it. And I use Omeka for research and course projects because the core developers and community contributors are producing an amazingly useful tool that I can trust because the people who make it are trained as historians and humanists.

**4. Prefer the tool used by the top people in your field. **If the top people in your field all use one tool, that’s what you should use too, so that you can learn from how they do their work. (This doesn’t really matter for writing; it matters more for data analysis and the like.) Most of the people I’ve come in contact with use Ruby, so that’s the language I’ve learned the best; under different circumstances, I would have learned a different language.

5. Prefer the current, stable version of software to the latest release. Particularly to people of a given mindset, the shine and jingle of new features can be quite alluring, but if it’s not broken, don’t upgrade it. Just as you overestimate the utility and underestimate the pain of switching tools, you will also make the same miscalculation about versions. Let naive users try out a new release and find all its flaws. You can jump in after the bugs are fixed. There’s a reason they call it “bleeding edge technology.”

6. Prefer the tool which you can learn about and customize to your workflow. The difference between professional tools and amateur tools is this. Amateur tools are easy to use from the start, and you’ll be just about as efficient with them on day one as you’ll ever be. Pro tools are hard to learn: you might completely flounder on day one. But because there is room to learn, you can learn to be vastly more efficient with them. That explains my love affair with Vim: it took me weeks to learn, but now the the biggest limitation on editing text and code is my brain rather than my tools. (Stephen Ramsay makes this point here and here and here.)

This set of guidelines is a rather conservative. You might justly ask, if I follow these guidelines, when would I ever try a new tool or new workflow? Indeed, for people like me and, possibly, people like you, limiting our proclivities to try something new instead of get something accomplished is precisely the point.

Still, there are a few good times to learn new approaches, tools, and methods. One of those times is in graduate school. Kieran Healy has an excellent paper on “Choosing Your Workflow Applications,” intended to teach graduate students and early career scholars in the social sciences how to do reproducible research. He writes, “If you’re in the early phase of your career as a graduate student … , you should give some thought to how you’re going to organize and manage your work.” I think he’s exactly right. Probably one of the most difficult challenges of the dissertation was figuring out how to organize my scholarly work to handle the volume of research and length of time that goes into a book-length as opposed to a seminar-paper-length project. Another time that it is appropriate to experiment with new ways of working is in between major projects.

I’m not saying you can’t try new software or tools if you want to and have fun doing so. Just don’t kid yourself that you’re doing work, and don’t fall into the trap of believing that it’s making you more productive.

What is your take? How do you think about which tools you use?

• I vaguely remember that someone, perhaps at ProfHacker, wrote a post on this same topic. If so, let me know who it was and I’ll give that person credit.