The book Thinking, Fast and Slow [amazon affiliate link] by Daniel Kahneman describes our brain as having two thinking systems, a fast one and a slow one. The fast system is automatic and multitasking, while the slow system is methodical and single-focussed. When you are doing something complex, you are usually concentrating your slow system on the main problem, while the fast system can be doing several related (and even unrelated tasks).

This is the main reason I try to memorize and practice several keyboard shortcuts for the programs I use every day. I am trying to get as much of the mechanics of the code editing into my automatic, fast thinking system.

There is a common belief that mousing is faster than keyboard shortcuts, which probably originated with this AskTog article:

We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

• Test subjects consistently report that keyboarding is faster than mousing.
• The stopwatch consistently proves mousing is faster than keyboarding.

This is probably true for the general case and for when the user is learning a new UI. But, the study, Comparison of Mouse and Keyboard Efficiency, suggests that:

[…] for heavily-used interfaces, keyboard shortcuts can be as efficient as toolbars and have the advantage of providing fast access to all commands.

For me, the key is that shortcuts have to be able to be deployed with no conscious thought.

Programming often requires you to keep several interrelated thoughts in your head until you get the code written and working. For example, even for simple web UI blocks, you have to think of the semantic structure of the tags, the layout, and the style. To write that code, you will have to possibly jump through a few files and parts of those files. So, to keep from adding more cognitive overhead, you want to make the manipulation of the editor as automatic as possible.

This is something I think that can never be accomplished with the mouse, but is possible for a small set of shortcuts. That set should be the most common actions that happen while you are actively programming. The goal is to keep your slow system and short term memory focussed on the programming task at hand.

For me, that is:

1. Cut, Copy, Paste, Undo, Redo
2. In-file navigation with arrows and modifiers (including using Shift for selection)
3. Find and multi-file Find
4. Show the current file in the project navigator
5. Open another file, tab cycling
6. Jump to the definition of the identifier under the cursor
7. Comment (or uncomment) the current selection

I do these commands all of the time. I often need to string a series of these commands together. Doing the equivalent without the commands risks engaging your slow thinking system and breaking you out of flow.

When showing progress, if you have a list of a known length and processing each item takes about the same time, you can implement it like this pseudocode:

for (int i = 0; i < list.length; ++i) {
    process(list[i]);
    // notifyProgress takes a numerator and denominator to 
    // calculate percent of progress
    notifyProgress(i, list.length);
}

One common problem is not knowing the length beforehand.

A simple solution would be to pick a value for length and then make sure not to go over it.

int lengthGuess = 100;
for (int i=0; list.hasMoreItems(); ++i) {
    process(list.nextItem());
    notifyProgress(min(i, lengthGuess), lengthGuess);
}
notifyProgress(lengthGuess, lengthGuess);

This works ok, if the length is near 100, but if it’s much smaller, it will have to jump at the end, and if it’s much bigger, it will get to 100% way too soon.

To fix this, we might adjust lengthGuess as we learn more:

int lengthGuess = 100;
for (int i=0; list.hasMoreItems(); ++i) {
    process(list.nextItem());
    if (i > 0.8 * lengthGuess) {
        lengthGuess = 2*i;      
    }
    notifyProgress(i, lengthGuess);
}
notifyProgress(lengthGuess, lengthGuess);

In this last example, whenever i is 80% of the way through, we set lengthGuess to 2*i.  This has the effect that the progress goes back and forth between 50% and 80% and then it jumps to the end.  This won’t work. 

What I want is:

1. The progress bar should be monotonically increasing
2. It should get to 100% at the end and not before
3. It should look as smooth as possible, but can jump

An acceptable effect, would be to progress quickly to 50%, then slow down to 75% (50% of the way from 50% to 100%), then slow down again at 87.5% (halfway between 75% and 100%), and so on.  If we keep doing that, we’ll never get to 100% in the loop and can jump to it at the end. This is like Zeno’s Dichotomy paradox (from the Wikipedia).

Suppose Homer wants to catch a stationary bus. Before he can get there, he must get halfway there. Before he can get halfway there, he must get a quarter of the way there. Before traveling a quarter, he must travel one-eighth; before an eighth, one-sixteenth; and so on.

To do that we have to keep a factor to use to adjust the progress we’ve made (playing around with it, I found that using a factor of 1/3 rather than 1/2 was more pleasing).

int lengthGuess = 100;
double begin = 0;
double end = lengthGuess;
double iFactor = 1.0;
double factorAdjust = 1.0/3.0;
for (int i = 0; list.hasMoreItems(); ++i) {
    process(list.nextItem());               
    double progress = begin + (i - begin) * iFactor;
    if (progress > begin + (end-begin) * factorAdjust) {                   
        begin = progress;
        iFactor *= factorAdjust;
    }               
    notifyProgress(progress, lengthGuess);
}
notifyProgress(lengthGuess, lengthGuess);

The choice of lengthGuess is important, I think erring on too small is your best bet.  You don’t want it to be exact, because we’ll slow down when we get 1/3 toward the goal (factorAdjust).  The variables lengthGuess and factorAdjust could be passed in and determined from what information you have about the length of the list.

If you are sending data from the iPhone to the Apple Watch, you might use sendMessage.

func sendMessage(_ message: [String : Any], replyHandler: (([String : Any]) -> Void)?, errorHandler: ((Error) -> Void)? = nil)

If you do this and get the error WCErrorCodePayloadUnsupportedTypes this is because you put an unsupported type in the message dictionary.

The first parameter (message) is a dictionary of String to Any, but the value cannot really be any type. If you read the documentation, it says that message is

A dictionary of property list values that you want to send. You define the contents of the dictionary that your counterpart supports. This parameter must not be nil.

“property list values” means values that can be stored in a Plist. This means you can use simple types like Int, Bool, and String and you can also use arrays and dictionaries as long as they are of those simple types (e.g. an Array of Ints)

I ran into this issue because I tried to use a custom struct in the message dictionary, which is not supported.

Note: I made this post because google is sending people to Programming Tutorials Need to Pick a Type of Learner because it mentions WCErrorCodePayloadUnsupportedTypes incidentally, but isn’t really about that.