The Brain-Hand Barrier

I’ve never been a particularly fast typist. Despite reading Steve Yegge’s very entertaining Programming’s Dirtiest Secret once every few months or so, I’ve been stuck in the 40 to 50 words-per-minute range for a few years now. Most of the time, this is not a big problem, for multiple reasons. In the last few months, I’ve been mostly writing code, not words (as witnessed by the rather low rate of posts on this blog). When you’re using a fairly succinct and powerful language (like OCaml) and working on research code, the major bottleneck to getting things done is often your thinking speed, not your typing speed. And for the rest of the times there are well-chosen Emacs keybindings deeply ingrained into your muscle memory.

I’d like to start writing more honest-to-goodness words—I’m pulling this blog out of the mothballs, I’m keeping a daily log of my research work and possibly a personal journal. And that’s on top of the usual emails and IMs and other sundry typing activities. As I’ve been ramping up my word count, I’ve been noticing something curious that’s purely anecdotal and quite possibly, completely wrong. But this is my blog and something is often better than nothing so I’m going to put it here for all eternity.

I claim (completely without proof) that when writing words (at least non-technical words) the bottleneck can often be your fingers. If you’re a slow typist (or an adequate typist, like me) you find yourself frantically trying to get ideas and thoughts down before they all slip away like water between your fingers. As a result, increasing typing speed can actually be better in at least two ways: first, typing faster lets you get raw thoughts down much faster leaving you time to come back and edit later. I know that a lot of people subscribe to the philosophy of writing slowly, even going so far as to using pen and paper to slow themselves down. Personally, I’m in the Hemingway camp — write drunk; edit sober. Since I have absolutely no intention of becoming an alcoholic, I’ll go with “write fast; edit slow”. It’s boring I know, but I like my liver and my brain cells.

Second, for a certain type of personality (including me), knowing that you’re fast enough to get something down without a major interruption in whatever else you’re doing makes you more likely to actually put it down, rather than having it banging around inside your head. For more on why getting things out of your head is helpful, I point you to the last book I read Overwhelmed: Work, Love and Play When No One Has the Time and a tl;dr review/article of the same name.

Both of the above are benefits from fast typing, apart from the professional benefits you might get (for which I point you back to Steve’s post).

So to conclude: type fast, type lots, edit slow, publish some. There’s probably a rant about RSI and how the Hobbit movies could have been made better and shorter with a good editor that can be extrapolated from that last sentence, but that will have to wait for another day.

Advertisements

My Emacs Config

I’ve released parts of my emacs configuration on Github. Fork away! I first started really getting into Emacs after reading Steve Yegge’s blog posts on the matter. Since then I’ve pretty much fallen in love with Emacs, waxed eloquently (or maybe not so eloquently) about why it’s a power tool and despite all the cool modern editors and IDEs you can pry my Emacs from my cold dead hands.

I add to my Emacs configuration every time I embark on a project in a new language or using a new toolset. Currently I have a good 15MB worth of Elisp code for programming in C, Python, JavaScript and Ruby, dealing with XML and Git, blogging with WordPress etc. etc. All that stuff is not in the repository (though the names of some of the packages are if you want them). What is on Github are my general Emacs configurations, custom keybindings and custom Elisp functions for moving around the buffer and relocating files.

A note on keybindings

Most of my keybindings are different from the standard Emacs ones. I rebound them to be easier for me to remember, especially the movement keybindings. The mnenomic I use is:

  • `f` key moves forward
  • `b` key moves backward
  • `d` key kills (deletes) forwards
  • `w` key kills (deletes) backwards

I use the Ctrl and Alt modifiers to make these actions work on words or individual letters. The Ctrl key makes each of the above operate by word and the Alt or Meta modifier makes them work by letter. The Ctrl-m combination is a prefix key for various functions to reposition the current open buffer in the window. The functions are defined in `functions.el`.

A note on tools

I’m a great believer in customizing and shaping your tools to fit your work and your workflow. However, I believe more strongly that the code is not the point and that your tools are definitely not the point. In keeping with that I rarely tinker with my Emacs setup nowadays: I’ve found a configuration that works for me and is acceptably efficient. If I move to new tools and language (Haskell and Go are on the horizon) then I might make more additions.

Sunday Selection 2011-11-20

Around the Internet

How an MIT postdoc writes 3 books, a PhD defense and 6+ peer-review papers and finishes by 5:30. One of the best and worst things about being in a PhD program is that it is opened: it can take as long as you want it. Though being at a world class research university like MIT or Cornell is certainly a wonderful experience, I’m not at the point in the life where I want to spend more than a few years in one place. I want to do good work, do it in a focused manner without killing myself and hopefully have a life and get done in a reasonable amount of time.

Thrust, Drag and the 10x Effect Managing your time goes hand in hand with managing your energy and your activities. In the software world there’s a claim that the best engineers are often ten times as productive as mediocre ones. This article aims to give you some tools to help you on your way toward being ten times as productive.

Why Emacs? I make no secret of the fact that I think Emacs is the best text-editing environment on the planet. This post gives a very straightforward but informative introduction to the question of “Why Emacs?”

Video

Derek Sivers’ Speech to Berklee College of Music I have a tremendous amount of admiration for Derek Sivers. While this speech is geared towards music majors, most of his lessons and advice can be generalized to your profession and life in general. There’s a lot of wisdom packed into a few minutes.

Software

Readability is an awesome tool in the fight for a reading-focused, cleanly designed web experience. They started as a browser plugin that strips a page of unnecessary clutter and presents just the text in a clean, visually pleasing format. They’ve released upped their game with a payment model for publishers, a rich web application and a review-pending iOS app. If you read a lot on the web you probably want Readability in your toolbar.

Moving to org2blog for publishing posts

For most of the last few years I’ve been using the WordPress online editor for writing posts. Part of this was because I moved between computers a lot and wanted to be able to get at my posts and drafts from wherever I was. But since I’m now using one machine for most of my writing (and all of my blogging) I’ve been able to finally move to centralizing all my writing under Emacs. Luckily I found a great Emacs mode that makes posting to WordPress a snap. org2blog is made to be used with org-mode files but by and large you can ignore the org-mode part (if you want to).

Org-mode is a helpful plain text mode for organizing notes, todos, agendas and even writing in general. I use it for taking notes about academic papers and meetings I go to. org2blog mainly uses the plain-text org format for setting up the metadata for the post — title, date, tags etc. But org-mode also makes inserting links easy and I’m much faster writing with all my Emacs editing shortcuts than I am in a text box in a browser. Org2blog then posts the org-file as draft (or published post) with a single command. I personally just save as drafts and then look at the preview before hitting publish. By writing in org-mode on a single I can also keep local backups of all my posts. Currently each post is just saved to a ByteBaker folder as a separate plain text file but I might put it all under version control at some point.

I have been toying with the idea of moving this blog off WordPress to a more home-brewed setup, but I haven’t been able to justify the time and effort it would take. Might be a winter project to get through the upstate New York winters. Personally as long as I have a trustable backup of all my code and add new things easily I’m fairly ambivalent about how the HTML actually gets generated and presented (especially if it’s done by open source software made by people I like). For the time being I’d rather invest in writing the blog than hacking it.

Mind Expansion

I think the world owes a debt of gratitude to Malcolm Gladwell. To my knowledge his book “Outliers” was the first popular work to expound at length on the 10,000 hour rule: the scientifically grounded theory that achieving expert level in most fields requires about 10,000 of “deliberate practice”. Geoff Colvin’s “Talent is Overrated” is similar, but in my opinion not quite as well written. However, both books are elements of what I see as a growing trend: the idea that improving yourself, becoming more than what you are, becoming what you always wished you were, is not only possible but actually achievable given a proper strategy and adequate dedication.

This idea of gradual, but consistent self-improvement isn’t just applicable to becoming top athletes or musicians. Tim Ferriss’ “The Four Hour Body” including the increasingly popular slow-carb diet applies a similar idea to health and fitness. Cal Newport, a recent MIT doctorate and professor at Georgetown seems to be applying similar ideas to becoming a top academic researcher. My personal goal is to apply it to become the best programmer I can possibly be (as most readers of this blog already know).

For a few weeks now I’ve had a two-fold concern. First, I didn’t know what exactly I was or wanted to be. Was I a programmer? A computer scientist? A software engineer? A technologist? A writer who just happened to use code as well as words? Secondly (and more importantly) I couldn’t see anything resembling a clear path from my current “not totally incompetent code slinger” phase to getting to the point where I could understand the works of the great masters (and maybe create something of similar lasting value). And that really, really bugged me. Combining my current indecision with no idea of how to move forward put me on a path leading straight to madness.

Here I was, a recent college graduate with two rather expensive degrees and a certain amount of knowledge about my field of interest. And yet my four years of education seemed like a piddly little drop compared to the proverbial ocean of knowledge and capabilities ahead of me. Not only could I not cross said ocean, I couldn’t even comprehend it’s boundaries. Sure I could write you a topological sort of some arbitrary graph structure. I could also bit-twiddle my way into a reasonably resource constrained embedded application. I’d even wager that I could build a reasonably stable concurrent system that isn’t too embarassing. But beyond that? I just barely grasped functional programming, my knowledge of type systems was rudimentary at best. I only had the foggiest notion of what a monad was and yet I had signed up for a good few years working on advanced programming languages. What on earth was I thinking?

One of the great dichotomies of our field is that on one hand it is possible to be completely self-taught but on the other there are few systematic guides on going from novice to expert. Most advice on the matter seems to reduce to “Read code. Write code. Think. Repeat.” Wise words to be sure, but not exactly a 12-step program. So what is one to do? What am I to do?

Though Gladwell and his ilk may have shown us that tangible self-improvement is possible, it’s not a quest to be taken lightly for there is no end to it. Until you come up against fundamental physical limits there’s always farther you can go, harder you can push yourself. And yet, after a point I’d argue that a law of diminishing returns kicks in, most victories past that point are Pyrrhic. Which is why it is important that I do what I do for fun, first and foremost. Because I find our field infinitely fascinating, constantly stimulating and there’s nothing else I’d enjoy more (though writing comes a close second).

After the why comes the how. What is the path from point A to point B? Where is point B in the first place? Do I even want to go there? Ostensibly I’m going to graduate school for Computer Science. I have a hard time calling myself a scientist or even a engineer. There’s a formality and heaviness about those terms that seems a little off, in the way that “colonist” has a different connotation than “explorer“. A colonist has a definite, long-term purpose – an unknown world to tame, a new land to cultivate and defend. An explorer is looking around, seeing the way things are, understanding and learning, eventually moving on. I’m content to explore for now. I think I’ll stay “just” a programmer for a while, or maybe even a writer, those two seem the best fit.

Though I do this for fun and computer technology has far-reaching effects on the human race, I’ve grown to see programming as a mind expanding activity in it’s own right, independent of other motivations and effects. I’m looking at our technology as a medium for creative expression. Programming is a way to become familiar with that medium, a way to increase our creative powers. And so the direction to explore is the one which will expand my mind the most, increase my creativity the greatest. It’s easy to stay within my boundaries, to stick to the stateful, imperative programming styles I’m familiar with. To go beyond that, to throw myself into functional programming, to use advanced type systems, to write compilers and virtual machines, to do all that, is hard. It is also a form of “deliberate practice” and essential to becoming better.

For fields and pursuits that aren’t easily quantified, deliberate practice is hard. However one heuristic is to look at how much a potential problem bends your mind. An interesting, worthwhile problem changes the way you think about your field in a general way, but requires you to acquire specific new techniques and skills. Once you solve the problems you’ve increased the size of your toolbox, but you’ve also changed how you will look at and approach problems in the future. With each problem you gain the capabilities to solve a wide range of new problems and inch closer to “expert” status.

A few weeks ago I tried looking for a 12-step program – an organized, decently, reliable path to becoming an expert programmer. I wanted a way to put in my 10,000 hours with a reasonable guarantee of a good payoff. I haven’t found such a plan, but I have found some principles – what I’m doing needs to be fun and must be mind-expanding. I have to keep programming, keeping reading and writing, keep thinking. I’ve reopened my computation theory books, I’m taking baby steps in Haskell, I’m scripting Emacs on a more regular basis. I’m trying to continually expand my mind and abilities, I’m trying to keep getting better. I hope in 10 years I’ll get close to where I want to be. But for right now, I’m drained.