Rules for Computing Happiness Revisited

About a year and half ago I wrote down some Rules for Computing Happiness. I based the list off of a similar list by Alex Payne. But in the year and half since then a lot has changed in my life. I graduated from college and finished a year as a graduate student at Cornell University’s computer science running experiments. I’ve also finally joined the world of smartphone users. I spend the greater part of the day writing programs and scripts and spend an increasing amount of time on remote machines. In the light of all those changes I think it’s a good idea for me to revisit the rules I laid down and see how much they’ve changed (or stayed the same). Here goes:

1. Use as few physical machines as possible

This one’s a keeper. I now use only two physical machines: my personal Macbook Air and my powerful Linux desktop at work. I use a combination of Git, Dropbox and Chrome tied to my Google account to keep things in sync between them. In reality the work I do on each doesn’t much overlap so there isn’t a pressing need to keep them in sync.

2. Keep work and play separate

Another keeper. I don’t have any social media apps on my work machine, I generally keep IM closed and I’m busy and in the flow enough that I don’t feel the need to randomly open up Reddit or Hacker News. I should be honest and say that this isn’t a purely (or even mostly) technical thing – in fact it probably has more to do with my shifting perspectives on what’s important. I have my phone near me if anyone really needs to get in touch with me. Since I’m a grad student I have a lot on my plate that is important but little that is urgent so my phone rarely gets used.

3. Get a Linux machine for programming. Use multiple monitors and a tiling window manager

I’m a bit less sure of this one and I’m partly afraid that I’m just plain biased. I do most of my programming on my Linux machine, but I do a decent amount on my Macbook Air too (especially experimental web stuff). I mostly use the UNIX in each so I’ve become fairly agnostic to what skin I’m running on top. I’ve never programmed on Windows so I don’t have anything to add on that matter.

However, I do use two monitors on a regular basis and going back to one can be annoying. I tried using Unity for a while and while it’s not bad, I keep going back to XMonad. It’s clean separation of physical monitors and virtual desktops makes using multiple monitors very flexible and efficient and I always find myself missing it when I’m on a different environment. By contrast, the way OS X does it is complete rubbish, especially if one of your windows is in fullscreen mode.

4. Get a Macbook for non-programming tasks

I’ve had my Macbook Air for over a year now and I love it. It’s the best laptop I’ve owned and probably the best computer ever. I only use a handful of userspace apps but they’re high quality ones like Reeder and OmniFocus. Homebrew is definitely the missing package manager for OS X and makes any programming I do a lot easier.

5. Keep a backup server, either physical or virtual

I’m still running a small Linode VPS that serves my personal website and acts as the syncpoint for my Git repos. I haven’t had any destructive crashes in the past year so I haven’t really felt the need for a backup, but it does offer peace of mind.

6. Learn and customize your tools

Yes, but do realize that it’s not the point.

7. Use public computers as little as you need to

Since I have both a great portable machine and a great workstation I haven’t had to use public computers at all. My desire to work in coffee shops and libraries has also been decresing steadily and I now prefer to work in a private office or a quiet shared workspace.

8. Pay for good software if you need it, but only after you’ve tried it out for a while

I’ve bought software like OmniFocus and Reeder and by and large I don’t regret it. I’m currently considering getting iA Writer. It’s cheap enough that I rarely think twice about gettting something that would make my job easier. However they “trying out” part is harder. My biggest gripe about the Mac App Store is no way to try out apps for a period of time (or stop using them and get a refund).

9. Keep information in open formats, preferably plain text

Yep. The only non-plain text format I interact with regularly is PDFs, only because that’s how most academic papers are distributed. I hold out hope that one day the academic community will move to publishing in hypertext.

10. Use version control on all projects

All my source code, my research data, my configs, my public and private writing are in version control. It not only makes it easy to go back and get something I may have overwritten, it also makes backup easier.

Process and Product

Yesterday I came across a post entitled “default behavior” by Ben Augarten about how important it is to put your products out in the world. It starts with him talking about how the code he’s writing is for an internal tool and hence will never see the light of day. Few people will use it and he’ll lose ownership of it once his internship ends. He implores programmers to release their code as products into the world and seems more than a little disdainful of programmers who don’t release their own products. He seems to be under the impression that if you’re not working on your very product that you’re dead inside.

He’s wrong.

It’s great to love to your product. It’s great to build something, to show it to the world, to have people use it, get feedback and make it better. If that’s what motivates you and makes you happy then by all means go ahead and release products. Life is too short to be unhappy (though people are working on that). What it doesn’t mean is that not releasing products makes you unhappy.

There’s a distinction to be made between process and product. Product is the fruit of your labor, process is the labor itself. In the rush to create startups, launch products, have dozens of repos on your Github account, we tend to lose sight of the process itself.

While I certainly understand (and have felt) the allure of releasing a product, there’s a lot of joy to be gained in the process itself. While many of us got into computers and programming because of the things we could create, many of us (including myself) got into it because of the joy of coding itself. I love learning new technologies, working through problems, crafting solutions. I love the mental strain of thinking my way to answer, I love the physical feel of my fingers on a keyboard and the seeing the characters of the screen. I love the process of seeing something being created as much I like the feeling of having created something. The same goes for writing or drawing or cooking – how you make something is just as important as what you make.

I suspect that this joy for the process itself is why so many incredibly talented and hardworking people are happy working for closed source companies (financial and material renumeration aside). If you are fulfilled by the labor itself then you care less about the fruits of your labor. This isn’t particularly new thinking – it predates open source, computers, software, even modern science and technology. As far as I know, the earliest well-known expression of such a notion is from the Bhagavad Gita where the god Krishna tells Prince Arjun:

“To action alone hast thou a right and never at all to its fruits; let not the fruits of action be thy motive; neither let there be in thee any attachment to inaction”

I don’t entirely agree with this: I do believe in property rights and I think that as a creator you deserve some say in how your creation is used. However I do agree with the underlying idea that you can find motivation in the actions themselves and not just their results. Getting too invested in the result can detract from joy you recieve from the process (and vice-versa). I’m not going to claim that process is better or more meaningful than product. Humans and their motivations and emotions are far more complex than such simple comparisons. But I am going to claim that finding fulfillment in the process itself is a perfectly valid way of living your life.

It’s great that Ben and so many other programmers and entrepreneurs want to create products and see them in action. We need that. They don’t have to become process-oriented. But they do have to understand that not all people will value products as much as they do and they have to respect that. Sometimes the journey is more important than the destination.

Sunday Selection 2012-07-01

Around the Web

Hackers and Fighters

When it comes to the debate between computer science and programming I’m of the opinion that knowing some computer science will make you a better programmer. Being a regular programmer will give you a better appreciation of the problems scientists need to solve. I’d love to see a proper scientific test of this hypothesis rather the jumble of anecdote and posturing that exists on the web today. This article is one of the more balanced ones and gives a worthwhile metaphorical veiw of the matter.

How One Hacker Quit the Programming Life for Bluer Skies

As much as I love writing code for my day job and wouldn’t be doing anything else, I don’t think that need be true for everyone. For a lot of programmers, writing code is just a day job and that’s ok. I find the notion that “real programmers” program day-in-day-night to be rather silly. You should do what makes you happy. Peer pressure that makes you produce more is still peer pressure. How good you are as programmer is determined by the quality of your code – not the hours you put in and not the number of open-source projects you maintain. And when you decide that you’ve had enough, don’t be afraid to go do something more interesting.

A much higher education

These are interesting times for academia and education in general. While I’m all for free (both as in beer and in freedom) digital distribution and decentralized, on-demand self-education, you can pry my expensive liberal arts education from my cold dead hands. I don’t think the higher-education system is unsustainable, I think there’s increasing pressure to commercialize and corporatize it and we’re unwilling to explore other options. Education is the foundation of a free society. Academic freedom is one of the pillars of modern science and technology. It’s about time we took that seriously.

Video

Jon Moore on Hypermedia APIs

Programming for the web is still one of my blind spots. That being said, I find the idea of programmatic exploration of APIs very interesting. I don’t fully understand all the implications and applications and I don’t think I will until I write a hypermedia application. But if you’re interested in knowing what programming for the modern web is like, I think this is a good start.

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.

The Code is Not the Point

There’s this meme in the programming community of thinking of our code as art. This is not a new phenomenon – it dates back at least to The Art of Computer Programming in 1968. More recently we have Paul Graham to thank for drawing the comparison between Hackers and Painters. With the rise of languages like Ruby and Processing and personalities like _why the lucky stiff programming has been gaining a reputation as an art form and a source of creative joy. And it should be. I love programming, it makes me feel good and I feel much better on days I’ve written code and produced something than on days I haven’t. However, I think the “code is art” or “programmers are artists” meme can be misleading because the code is not the point.

Miyamoto Musashi was a medieval Japanese swordsman and Ronin, widely regarded as the best swordsman of all time. He was also the author of a book titled “The Book of Five Rings” – a book on swordsmanship, strategy, tactics and philosophy that is still relevant today. There is one passage in the book that is relevant to our discussion:

The primary thing when you take a sword in your hands is your intention to cut the enemy, whatever the means. Whenever you parry, hit, spring, strike or touch the enemy’s cutting sword, you must cut the enemy in the same movement. It is essential to attain this. If you think only of hitting, springing, striking or touching the enemy, you will not be able actually to cut him.

The primary thing when you take an editor in your hands is your intention to solve the problem, whatever the means. Whether you write a script, a unit test, a function, or a library, you must move towards the solution in the same movement. It is essential to attain this. If you think only of scripts, tests, functions or libraries, you will not be able to actually solve the problem.

Because the code and it’s surrounding artifacts, including your sense of beauty, is not the point. It does not matter how much code you’ve written, what your test coverage is, how much you’ve learned in the process, if you haven’t not solved the problem (or solved it inadequately, or solved the wrong problem). Anything that does not bring you closer to your solution is suspect.

Does this mean that clean code, good comments, test coverage are not necessary or important? Of course not. If your code is not well-written and clear, are you sure you’ve solved the problem? If you have no tests, are you sure you’ve solved all aspects of the problem? If you have no documentation, how will others use and improve on your solution?

Does this mean that your code is not art? Does this you mean you should not carry an artists’ sense of elegance and aesthetics? Of course not. By all means take pride in your work. Make it a point of honor that others can understand your code without sending a dozen emails. Please aim for the solution that is not just correct, but also elegant, concise and efficient.

But keep in mind that the code is not the point. Beauty, elegance and pride are no substitutes for correctness. We are scientists and engineers first, artists second. If the theory does not fit the facts, if the code does not solve the problem, it must be discarded no matter how beautiful it is.

I don’t think of myself as an artist any more. My code is not art. I take pride in my work but it is the pride of an engineer. I want my code to have more in common with a Rolls Royce engine than it does with Sunflowers. I try to do the cleanest, most elegant job I can. But whenever I write code, the intention is to cut the enemy, whatever the means.