Developing Software Productively through selective automation

How do you increase your software development productivity over the long haul? Here's how: Examine your daily task work to identify tasks that are amenable to automation, and then automate it. For me, this means to do the following:

1. Maintain a constant awareness of all of your development activities, specifically patterns of behavior or groups of actions that are repeated multiple times throughout the day.
2. Of those patterns, identify the ones that are comprised of tasks that do not change regardless of the circumstances.
3. Determine if those tasks are amenable to automation (some will, some won't). This excludes tasks that should be delegated to someone else to do.
4. Schedule time to encapsulate the tasks in a software routine.
5. Make executing that routine mindless and effortless, by associating the execution of the routine to a new and unique combination of key-bindings in the main window of the primary editing tool you use (e.g. Emacs, Eclipse, Jedit, etc.).

Some may think that the "schedule time" item will eat into their productivity. However, I have found in practice that the time saved by automation will pay for itself over time. But there is one more benefit: Having a machine execute the tasks frees up your mind to think at a higher level of abstraction, in a given project. Making a task mindless and effortless has the goal of not distracting your mind from the flow of adding, deleting, and moving code around. Any requirement to pull down menus, bring other windows to the front, type in and execute long command lines, etc., are distracting to the mental process of software development and should be gradually eliminated by delegating those tasks to push-button automation. Therefore, as a software developer, those activities are best done right there in the text editing window itself, to be driven by carefully chosen key sequences that are easy to memorize. Below are some examples of tasks I discovered fit the above criteria, and that I could automate (this is specific to my focus on code development, but they could be generalized for other work domains):

1. When the cursor is on a full or relative path to a file somewhere on the filesystem, typing a keystroke to open the file in the text editor. Compare that to opening up a new window, moving the mouse cursor into that window, navigating a file browser to find the file or typing in the full path to the file in the file system. Think about how often that task is done in given developers work day.
2. When the cursor is sitting on a URL, typing a keystroke to open the URL in a browser. Think about how often you need to refer to reference material that is only on some remote web server somewhere.
3. When the cursor is sitting on a symbol whose definition you need to alter, typing a keystroke to drive your editor to view and edit that definition. Compare that with using a file search to find the definition, and filter out the false positives.
4. You need to go back to where you started when editing some code, so type a keystroke to go back to the place where you started. The idea here is that each time you navigate to a new view on some source, there is the equivalent of a "back" button in the form of a key sequence. This should be applicable for all types of navigation to some file, symbol, or web page.
5. You need to reload your brain with the context after an interruption. The thing being automated away is the time wasted wondering where you left off, or clicking through various windows or views to answer that question. The solution is to track notes of decisions you are making in a searchable set of interlinked note files. This excludes writing them down on paper, since there is no search capability (and filing cabinets and other filing systems are yet another mental distraction). In my case, I use multiple text files that are interlinked (Muse mode in GNU Emacs). This also pays dividends later on when you need to refresh your memory on decisions that were made on the project done months later.