Programer Workflow Efficiency
so, i've been quite concerned about efficiency. That is, programer operating the computer, and especially in emacs.
this is almost a science/art by itself.
workflow are diverse. Thousands of ways. Let me give a illustration from coding.
given a program, there are thousands of algorithms that arrive at the same result. And, to code a particular algorithm using a given language, there are again thousands ways.
workflow is similar to that. There's vi, there's emacs, there's many different IDEs, and different OS compel you to do things in a particular way, with different key shortcuts.
but, let's narrow it down. Let's say we are all using emacs, on Linux. Still, there are hundreds of different workflow from many different aspects. There's the default GNU Emacs keybinding, then some uses cua-mode, some ergoemacs or evil/viper. These are not just key differences, but effect how you select, how often you select, how you move the cursor, how often you use particular command (commands with easy keys induce you to use it more often, and these modes have their own new commands too). Then:
- some do use mouse to select text, jump to point, or scroll page, while others not much.
- some always max window, some never.
- some use virtual screen (aka workspace), some never.
then, there are hundreds of ways people differ in switching buffers. I for example, don't keep more than 20 buffers open at any time. I close it immediately when not needed. Many, often have hundreds buffers open. For them, efficient buffer switching becomes critical. For me, efficient way to open particular files, or close files, is critical.
some prefer working in 1 single emacs window, full-screen, with multiple split panes. Others prefer multiple smaller windows. The two methods creates significantly different workflow on how you open files or switch windows. Full-screen people require powerful management of the split-panes, while multiple-windows user require good methods to switch among windows. [see Emacs Workflow: Fullscreen vs Multiple Frames]
so, there's all these bewildering workflows, and basically each person is slightly different from other.
even though we assumed emacs on Linux, there's still other critical aspects such as what desktop one is using. For example: Ubuntu Unity, Gnome, KDE, xfce, or other weird windows managers. [see Intro to Linux Window Manager and Desktop Environment] Also, whether one uses terminal much, or stick within emacs only.
the desktop environment has significant influence on your workflow.
also, all different workflow is usually unknown to others. The only way to know the hundreds of workflow other than your own, is to actually have worked with another person for a period of time. (For example, a co-worker, in some agile team)
so, when discussing many of emacs aspects such as modes, keys, you see each swear by their methodologies, keys, often with strong opinion and self satisfaction, but most people haven't seen many other workflows.
but, given all these diverse workflows, does it mean efficiency cannot be judged or qualified or measured?
efficiency can actually be judged. That's the point i want to make (it's what prompted me to write this post extempore).
you just need to interact with lots people (here, meaning other emacs users on linux), in real-life. Then, you can get a sense of different workflow, their efficiency.
sometimes we see video clips of other emacs users. But that doesn't help much, because a vid clip only shows a particular method or command or mode, usually refined. It doesn't capture the whole picture.
end of quick type of thought flow. =(^_^)=
so, anyway, to recap:
- workflows are diverse.
- usually it's hard for a person to know other's workflow.
- workflow doesn't quantify or communicate well. (because each person can only know 20 or 30 other programers well)
- fast operation does not equate efficient workflow. You may be operating extremely fast with muscle memory, but a alternative workflow might require half of keystrokes and or less required brain processing. (For example, (1) fast typer vs someone who uses a good template system. (2) default GNU emacs keybinding vs evil-mode user. (3) a key F8 to switch to emacs vs Ctrl+Tab that requires brain processing.)
- the workflow efficiency can be scientifically measured. For example, start by giving a rough definition of what needs to be done (For example, switching windows/top, open/close, files…), and have a stat that measure key strokes, measure timing, etc. Also, by analysis of the operation. Compare the keyboard shortcut's ease-of-operation, compare efficiency of the operation (For example, mouse to click a link vs keys to move cursor to a link, typing programing constructs vs a template system.)
- we need to spread the awareness of this.
vim-Golf is Localized Workflow Comparison
you know about vim-golf? There, we can see a lot different workflows, within vi. But, it's a local workflow. That is, the context is extremely narrow. You are given a piece of text and you want to edit it to transform to the given result. You don't have to deal with switching windows, opening different tabs for reference, close tab/file/window, copy/paste between apps, etc.
Google Does Workflow Study, on Browsers
Google does have lots of scientific studies on workflow, i think, but usually for web browsers, and they are focused for the type of people who hardly know how to copy＆paste. Google does this to improve their UI design. Their goal is different from creating a efficient workflow for programers, but their study would be something similar to what we are discussing here.
Longtime Emacs Users Tend to Create Unique Workflow
once you worked with a tool for a long time, one tends to develop one's own unique and weird workflow, especially with emacs or Linux. That is, you eventually have modified the tool extensively to suite your own peculiar growth. This is interesting, because, you can think of a workflow as going from point A to B in the Traveling Salesman problem. Using standard or default tools, keys, would be likened to following the trodden path. (there are still great diversity) But for emacs users who learned lisp, he starts to customize his ways with his own elisp command/function/packages that his workflow is foreign to others. The personal customization may eventually become published packages, and may eventually be adopted by the community. For examples of emacs, helm and icicles are good examples of eventual public packages, yet they are used by relatively few people (because they are not bundled, and they require non-trivial learning). Similarly, in Linux, you have great number of weird window managers.
Advanced Workflow Requires Non-Trivial Learning
another interesting point is that, a given tool or environment requires learning. We often don't think much of it, but if you are a Microsoft Windows user and just switched to Mac or Linux, your productivity would grind to a halt. You have to learn the proper tools for editor, for ftp, for connecting remote server, for system config, and find and learn lots of other tools you need daily. Similarly, switching from Microsoft Visual Studio to emacs or vi would drop productivity to the ground, in the beginning. Same for vi to emacs etc. And, even within emacs, if you take away my own personal settings, i'd be crawling like a Notepad user.
Workflow Are Shaped by Your Tools
workflow are often shaped by the tools you work with. For example, emacs by default makes it hard to close a file (kill buffer), but makes it easy to switch or hide buffers. So, most long time users leave hundreds of buffers open, but have efficient ways to hide or switch them. There are many ways to get to a point, one tends to follow the immediate easy path (as in greedy algorithm).
in other words, often you adopt to the tools, instead of the tools adopting you. Emacs is perhaps the best tool that adopt users. But even so, a tool's default settings has major impact on your workflow. (this is similar to how programing languages influence code patterns. (lisp is in general known as the most flexible, while Java the least))
See also: Game: Emacs of the Dead