Productivity

Life lessons from functional programming

Posted on by John

Functional programming languages are either strict or lazy. Strict languages evaluate all arguments to a function before calling it. Lazy languages don’t evaluate arguments until necessary, which may be never. Strict languages evaluate arguments just-in-case, lazy languages evaluate them just-in-time.

Lazy languages are called lazy because they avoid doing work. Or rather they avoid doing unnecessary work. People who avoid doing unnecessary work are sometimes called lazy, too, though unfairly so. In both cases, the term “lazy” can be misleading.

Imagine two computers, L and S. L is running a queue of lazy programs and S a queue of strict programs. L may do less work per program by avoiding pointless calculations. But it may accomplish more productive work than S because the time it saves executing each individual program is used to start running the next program sooner. In this case the lazy computer is getting more productive work done. It seems unfair to call the computer that’s accomplishing more the “lazy” computer. This also could apply to people. Sometimes the people who don’t appear to be working so hard are the ones who accomplish more.

A person who approaches life like a strict programming language is not very smart, and even lazy in the sense of not exercising judgment. Conversely, someone who bypasses an unnecessary task to move on to necessary one, maybe one more difficult than the one skipped over, should hardly be called lazy.

Related posts

Do you need a to-do list?

Posted on by John

Jeff Atwood wrote the other day that if you need a to-do list, something’s wrong.

If you can’t wake up every day and, using your 100% original equipment God-given organic brain, come up with the three most important things you need to do that day – then you should seriously work on fixing that. I don’t mean install another app, or read more productivity blogs and books. You have to figure out what’s important to you and what motivates you; ask yourself why that stuff isn’t gnawing at you enough to make you get it done. Fix that.

I agree with him to some extent, but not entirely.

The simplest time in my life was probably graduate school. For a couple years, this was my to-do list:

  1. Write a dissertation.

I could remember that. There were a few other things I needed to do, but that was the main thing. I didn’t supervise anyone, and didn’t collaborate with anyone. My wife and I didn’t have children yet. We lived in an apartment and so there were no repairs to be done. (Well, there were, but they weren’t our responsibility.) There wasn’t much to keep up with.

My personal and professional responsibilities are more complicated now. I can’t always wake up and know what I need to do that day. To-do lists and calendars help.

But I agree with Jeff that to the extent possible, you should work on a small number of projects at once. Ideally one, maybe two. Not many people could have just one or two big things going on in their life at once, but more could have just one or two things going on within each sphere of life: one big work project, one home repair project, etc.

Jeff also says that your big projects should be things you believe are important and you are motivated to do. Again I agree that’s ideal, but most of us have some obligations that we don’t think are important but that nevertheless need to be done. I try to minimize these — it drives me crazy to do something that I don’t think needs to be done — but they won’t go away entirely.

I agree with the spirit of Jeff’s remarks, though I don’t think they apply directly to people who have more diverse responsibilities. I believe he’s right that when you find it hard to keep track of everything you need to do, maybe you’re doing too much, or maybe you’re doing things that are a poor fit.

Related posts

It’s not the text editor, it’s text

Posted on by John

Vivek Haldar had a nice rant about editors a couple days ago. In response to complaints that some editors are ugly, he writes:

The primary factor in looking good should be the choice of a good font at a comfortable size, and a syntax coloring theme that you like. And that is not something specific to an editor. Editors like Emacs and vi have almost no UI!

To illustrate his point, here’s what my Emacs looks like without text:

There’s just not much there, not enough to say it’s pretty or ugly.

When people say that Emacs is not pretty, I think they mean that plain text is not pretty.

For better and for worse, everything in Emacs is text. The advantage of this approach is consistency. Everything uses the same commands for navigation and editing: source code, error messages, directory listings, … Everything is just text. The disadvantage is that you don’t have nicely designed special windows for each of these things, and it does get a little monotonous.

When people say they love their text editor, I think they love text. They prefer an environment that allows them to solve problems by editing text files rather than clicking buttons. And as Vivek says, that is not something specific to a particular editor.

Related posts

Work or rest

Posted on by John

According a recent biography of Henri Poincaré,

Poincaré … worked regularly from 10 to 12 in the morning and from 5 till 7 in the late afternoon. He found that working longer seldom achieved anything …

Poincaré made tremendous contributions to math and physics. His two-hour work sessions must have been sprints, working with an intensity that could not be sustained much longer.

I expect most of us would accomplish more if we worked harder when we worked, rested more, and cut out half-work.

Update: To be clear, the quote above refers to Poincaré’s most intellectually demanding work. Poincaré carried on his administrative duties outside the four hours of concentration mentioned above.

Bicycle skills

Posted on by John

A while back I wrote about learning things just-in-case or just-in-time. Some things you learn in case you need them in the future, and some things you learn as needed.

How do you decide whether something is worth learning ahead of time, or whether it is best to learn if and when you need it? This is a common dilemma, especially in technology. There’s no easy answer. You have to decide what is best in your circumstances. But here’s a suggestion: Learn real-time skills and bicycle skills in advance.

A real-time skill is something you need for live performance. If you’re going to speak French, you have to memorize a large number words before you need them in conversation. Looking up every word in a English-French dictionary as needed might work in the privacy of your study, but it would be infuriatingly slow in a face-to-face conversation. Some skills that we don’t think of as being real-time become real-time when you have to use them while interacting with other people.

More subtle than real-time skills are what I’m calling bicycle skills. Suppose you own a bicycle but haven’t learned to ride it. Each day you need to go to a store half a mile away. Each day you face the decision whether to walk or learn to ride the bicycle. It takes less time to just walk to the store than to learn to ride the bicycle and ride to the store. If you always do what is fastest that day, you’ll walk every day. I’m thinking of a bicycle skill as anything that doesn’t take too long to learn, quickly repays time invested, but will never happen without deliberate effort.

When you’re under pressure, you don’t learn bicycle skills. You don’t make long-term investments, even if the “long-term” is 30 minutes away. I’ll just walk, thank you.

What are bicycle skills you need to learn, things that would save time in the long run but haven’t been worthwhile in the short term?

Editing by semantic units

Posted on by John

The most basic text editor commands operate on lines and characters: move up or down a line, delete the next or previous character, etc. More advanced commands operate on context-specific semantic units. In the context of English prose, this means words, sentences, and paragraphs. In the context of source code, it means blocks and functions, however these are delimited in a particular language. In the context of an outline, it means navigating the tree.

One way to become more proficient at using your editor of choice is to become fluent at working with larger semantic units. Of course this saves keystrokes, though as I argued here, I don’t think typing speed matters so much. However, working in larger semantic units reduces errors. It also improves the chances that you can act on an idea before you forget what you were doing. These factors matter more than typing speed per se.

The general principles above apply to any editor. Here I’ll sketch how these ideas work in Emacs.

As a general rule, commands that operate on physical units begin with Control and analogous commands that work on semantic units being with Meta (Alt). For example, C-f moves forward a character and M-f moves forward a word. C-e moves to the end of a line and M-e moves to the end of a sentence.

Emacs extends the meaning of prose units by analogy in other contexts. For example, in calendar mode, a “line” corresponds to a week, and a “paragraph” corresponds to a month.

Emacs has numerous commands to work on “balanced expressions,” i.e. text surrounded by parentheses, brackets, braces, quotation marks, etc. Often the default keybindings are consistent with those used for other units. For example, “f” means forward and “b” means backward in any context. C-f and C-b move by character, M-f and M-b move by word, and C-M-f and C-M-b move by balanced expression. Emacs also has commands for working with function definitions: selecting a function definition, moving to the beginning or end of a function definition, etc. In Lisp, function definitions are balanced expressions. In other languages, like C, these ideas are distinct.

This morning, Irreal points out an Emacs package expand-region that selects larger and larger semantic regions. The first time it is invoked, it selects the immediate context of the cursor. Each subsequent invocation selects a larger context, moving up the parse tree of the content. I look forwarding to trying it.

Relearning to type

Posted on by John

I’m starting to feel some strain in my hands, so I’m going to take Vivek Haldar’s advice:

Act like you do have RSI, and change your set up right now to avoid it.

For one thing, I bought an ergonomic keyboard this weekend. It lets me hold my hands in a more relaxed position.

When I learned to type, I learned to use the shift key on the opposite hand of a letter to capitalize it. For example, holding down the shift key with my right hand to type an A with my left hand. But for some reason, I never developed the analogous habit for the Control and Alt keys; I only use these keys with my left hand. So while I’m getting used to a new keyboard, I’m going to try to use Control and Alt on the opposite hand of the letter they modify.

I may also try remapping another key to be the Escape key. I use Emacs, so I use the Escape key frequently. Some people recommend remapping Caps Lock to be an Escape key. I currently have the Caps Lock key mapped to be a control key. I may go back to using the default left control key and use Caps Lock as the Escape key. Or maybe I’ll remap the context menu key between the Alt and Control keys on the right side since I never use it.

Related links

Obsession

Posted on by John

Obsession has come to have a positive connotation. Individuals and companies brag about being obsessed about this or that. But obsession is a psychosis, and the original meaning of the word is still valid.

Obsession, according to the canons of psychology, occurs when an innocuous idea is substituted for a painful one. The victim simply avoids recognizing the thing which will hurt. [source]

Obsession with small things is a way to avoid thinking about big things. Maybe our company is sinking like a rock, but our website is valid XHTML 1.1! Maybe my relationships are falling apart, but I’ve almost got all my GTD applications configured the way I want them. Maybe my paper makes absolutely no contribution to science, but now I’ve got another publication.

Paying attention to detail because it is important is not obsession. And when people brag about being obsessed, they’re probably trying to imply that this is what they’re doing. Details matter in relation to a bigger picture. Focusing on details in isolation, hoping that the bigger picture will take care of itself, is obsession.

Criteria for a computing setup

Posted on by John

“My setup” articles have become common. These articles list the hardware and software someone uses, usually with little explanation. The subtext is often the author’s commitment to the Apple brand or to open source, to spending money on the best stuff or to avoid spending money on principle. I don’t find such articles interesting or useful.

Vivek Haldar has written a different kind of  “my setup” article, one that emphasizes the problems he set out to solve and the reasons for the solutions he chose. Here are a couple excerpts describing his goals for preserving his data and his health.

Try to remember the oldest digital artifact that you can still retrieve, and more importantly, decode and view. Can you? How old is it? That should give you some idea of how hard and full of unknowns the problem of long-term preservation is. …

If a significant fraction of your working life is spent working with computers, and you do not yet have even the mildest RSI, you should consider yourself extremely lucky, but not immune. Act like you do have RSI, and change your set up right now to avoid it.

I thought the best part of the article was the criteria, not the solutions. It’s not that I disapprove of his choices, but I appreciate more his explanation of the rationale behind his choices. I don’t expect anybody is going to read the article and say “That’s it! I’m going to copy that setup.” I gather that in at least one detail, his choice of version control system, Vivek wouldn’t even copy his own setup if he were to start over. But people will get ideas to consider in their own circumstances.

Related post: Ford-Chevy arguments in tech

iPad as hip flask

Posted on by John

I reread Paul Graham’s essay The Acceleration of Addictiveness after a friend quoted it in a blog post explaining why he is taking an indefinite hiatus from social media. I hadn’t noticed this gem in the footnotes when I first read Graham’s essay:

Several people have told me they like the iPad because it lets them bring the Internet into situations where a laptop would be too conspicuous. In other words, it’s a hip flask.

Related post: How to neutralize intelligence