A Personal Journey in Editing Programs

Over the past year or so, I’ve spent a bit of time tinkering with text editors. It feels like I woke up one morning and was simply dissatisfied with what I was currently using. It certainly wasn’t disgust, because I largely like the tools I use. But I felt it was likely there were better tools out there, and that I should give them an honest try. The grass on the other side might be greener.

So I went through liasons with VIM and a couple with Emacs. The first left me feeling disconnected, like I had ideas but I couldn’t even make them appear on the screen, let alone run. My experiences with Emacs are better, but have always felt somewhat awkward. I suspect that at some point, I could be a full-blown Emacs person, but right now, I’m just an aspirational Emacs guy.

I’ve used a myriad of editors in my time. I started with jed, a small-ish Emacs clone, then graduated to full-on Emacs. By way of viper, I migrated to VIM. Then I picked up BBEdit, because I wanted more direct manipulation of text, and less of a never-ending learning curve. I was pretty quick to jump on TextMate, seeing a great fusion of the Mac and Unix aesthetics.

I still think TextMate is as close as it gets to an ideal situation. And yet, it falls short enough that I tinker with VIM and Emacs, two editors that can easily be labeled powerful but extremely lacking in the visual and conceptual aesthetics departments.

I suspect my mismatch with most of these editors is due to something about my habits, the way I like to work with programs, and the kinds of programs I work with. Emacs’ notions of major and minor modes doesn’t play well with markup files with three different languages embedded within. VIM is efficient for those who have internalized it and hostile to everyone else. TextMate is easy to get started with and pleasant to extend up to a point, but seems to have fallen victim to its creator’s perfectionism.

For a long time, I’ve adhered to the philosophy that one should choose one text editor and learn as much about it as possible. Increasingly, I’m starting to think that there is no panacea, no "one true editor". TextMate is great for working on web apps and easy to extend. Emacs is really wonderful for functional programming languages, especially those with REPLs and languages that are LISP-shaped. And some kinds of development demand an environment more like Smalltalk browsers than text editors.

My journey for editing bliss probably won’t end anytime soon. In the future, I suspect that it’s going to be a spectrum of tools depending on the work I’m doing. It could be that the days of personal text editing monoculture are over.

A Brief Survey of the History of Editing Programs

Software developers spend a lot of time working with code. Over the past half-century of doing so, we’ve invented a lot of mechanisms that make that task easier and reduce the amount of friction between an idea and a computer executing that idea.

A quick review of the approaches to working with code reveal some areas where tool makers have devoted a lot of effort:

  • Editors — we’ve gone from paper tape to punch cards, from flipping switches on a panel to editing files one line at a time, and finally to the point where (most of us) work with one or more files by directly manipulating the text with a combination of keystrokes. When you get down to it, the experience of editing code in Emacs, TextMate, Visual Studio, or Eclipse are quite similar.
  • Environments — many software developers today use some kind of full-screen tool that puts a friendly face on all the tools they need to create, edit and deploy their software. These days, it is most commonly an IDE like Visual Studio or XCode. But way back in the day, Smalltalk people used a clever piece of technology called a browser, and it’s not too much of a stretch to call Emacs a Lisp browser.
  • Tools — we’ve come a long way in fifty years. We started writing machine code directly, then we grew assemblers, linkers, and compilers. Today, few developers will go through their career without using a debugger, profiler, lint tool, or applying an automated refactoring. There are a lot of development tasks that can be offloaded directly to the computer, leaving the programmer free to worry about important things like why anyone would ever choose three-space tabs.

Finally, let’s not forget that the past half-century of software development has seen more than its fair share of programming languages. These languages express a myriad of ideas and the ones that combine them nicely and support their users well have left a lasting impression in the evolution of how we express our ideas so that computers can run them.

It seems we are nearing an inflection point with regard to how we use tools to create programs. As the keyboard-and-mouse give way to the display-and-finger(s), there’s an opportunity to interact with and modify programs in new ways. I suspect that the future of editing programs has something to do with merging editors with environments and making the tools as pervasively used as typing is today.

Who are we that make software?

We who spend all of our time in front of a computer involved in the production of software are often quick to pigeon-hole ourselves. You probably self-classify as a developer or designer, maybe an engineer or artist if you got a college degree and think highly of it.

But like many other things, it’s all messy now. I’d say I spend sixty percent of my time doing general “developer” stuff, twenty-five percent doing something one could approximately call “engineering”, and split the rest between marketing, business, and design.

Does self-identifying with any one of these roles limit how we think or approach doing what we do?

Sloppy classifications

Consider these heuristics for placing people into categories:

  • You build things that face other people
  • You are making things that are constrained by rulesets defined largely by Newtonian mechanics
  • You are making things where trade-offs between aesthetics and affordances are made
  • Other people build things on top of your things

None of these are useful at all. Were you to provide any one as a definition of what an engineer or designer is, you could probably get some heads nodding. So there’s something appealing about each of these statements. But none of them provide a pleasing definition or guideline for when you’re doing engineering, development, or design.

Part of the answer to these classifications is that we all do everything. Developers strive to build software that fits within the aesthetic of the code around it or their own personal aesthetic. Designers operate within the limitations of human perception and cognition. Engineers are constrained by both of these but will throw either out in a heart beat to improve upon the efficiencies that are important to the project at hand.

We’re all hybrids

The notion of developing designers and designing developers is by no means new. A few examples:

But consider Kent Beck, renowned for his work building and thinking about the process of building software. He often talks about the design of software, considering trade-offs, aesthetics, and affordances just like a designer does. But he’s also been spending a lot of time recently iterating on businesses, trying out new ideas, and writing about the process and essence of converting an idea into a sustainable business.

Or consider Shaun Inman. He’s writing games as a one-man show. He splits his time between producing the music, drawing pixel art, and coding up collision detection systems. That’s a pretty neat cocktail of talents.

If you’ve ever bikeshedded a design discussion or suggested how a feature might work, you’re a hybrid. Ever refer to yourself as a specializing generalist? That’s a hybrid.

Directed thought

If you’ve self-classified one way or the other, there are little things you might do that have large effects on your thinking. You socialize with those who are like classified, use the tools of that classification, and concern yourself with the classic problems that consume those working in your area of specialization.

If you’re not careful, you could box yourself in too much, become too specialized. While there are opportunities for well-chosen, tightly-focused specializations, they are few and far between. Specializing generalists are the order of the day.

Where do we get if we acknowledge that we’re all hybrids now? Suppose you’re aiming for a balance of sixty percent developer, twenty percent engineer, and twenty percent designer. Is it worth going whole-hog learning Emacs or Photoshop? Or is it better to learn less-capable but lower learning-curve tools like TextMate and Acorn? Should such a person concern themselves with the details of brand design and the implementation of persistent data structures, or is it more important to grasp those topics in a conversational manner?

Is it a better use of Shaun Inman’s time to dissect a Mahler symphony, do an expansive study of pixel art, or review the mechanisms Quake III used for detecting collisions? Is it a better use of Kent Beck’s time to build software and write about that process, to talk to people and integrate their problems into his way of developing software, or iterate on business ideas and share those experiences?

Here's the motivational part

So now that all of this is forehead-smackingly clear (right?!), where do we go from here? Personally, I’m using the idea to guide how much effort I put into teaching myself new tricks. I probably won’t go on a six-month algorithms kick anytime soon, but I might spend six months learning the pros and cons of various database systems or application frameworks. I’d love to spend a month just tinkering with typography, color, layout, and other visual design topics. I probably won’t sweat it if Emacs or Photoshop don’t integrate into my daily work too well, or prove impenetrable to my mind, since those tools imply workflows that aren’t top priority to me.

But that’s me; where should you go? If you don’t already have a good idea of what kind of hybrid you are, start noting how much time you spend on various sorts of tasks and think about whether you’d like to do more or less of them. Then, start taking action to realize a course correction.

You can be whatever kind of hybrid developer you want, it’s just a matter of putting in the time and effort.

Those who think with their fingers

In the past couple of years, I’ve discovered an interesting way to think about programming problems. I try to solve them while I’m away from the computer. Talking through a program, trying to hold all the abstractions in my head, thinking about ways to re-arrange the code to solve the problem at hand whilst walking. The key to this is that I’m activating different parts of my brain to try and solve the problem. We literally think differently when we talk than when we write or type. Sometimes, the notion you need is locked up in other parts of your brain, just waiting for you to activate them.[1]

But sometimes, when I’m doing this thinking, there is something I really miss: the feel of the keyboard under my fingers and the staccato of typing. If there’s an analog to “I love the smell of napalm in the morning”, it’s “I love the sound of spring-loaded keys making codes”.

With the release of the iPad, it’s quite likely that a large percentage of the population can start to eschew the traditional keyboard and pointer that have served them in such a mediocre fashion for so long. On the other hand, you can take my keyboard from my cold dead hands. I really like typing, I’m pretty good at it, and I feel like I get a lot done, pretty quickly, when I’m typing.

Last year, I decided I would give other text editors a try. I stepped out from my TextMate happy place to try VIM. I knew this part of the experiment wasn’t going to work because when I felt like I’d gone through enough reading, tutorials and re-learning of VIM, I sat down to tap out some code. And…nothing. I felt like I was operating the editor instead of letting the code flow from my brain, through my fingertips, onto the display. It was as if I had to operate through a secondary device in order to produce code.

Sometimes it seems that developers think with their fingers. I’m not sure what the future of that is. We’ve created environments for programming that are highly optimized for using ten fingers nearly simultaneously. How will that translate to new devices that focus on direct manipulation with at most two or three fingers at a time. Will new input mechanisms like orientation and acceleration take up the slack?

Will we finally let go off the editor-compiler-runtime triumvirate? Attempts to get us out of this rut in the past have proven to be folly. I’m hoping this time around the externalities at the root of past false starts are identified and the useful essence is extracted into something really compelling.

In the mean time, it’s going to be fun trying the different ways to code on an iPad as designers and developers try new ways to make machines do our bidding.

1 If this intrigues you, read Andy Hunt’s Pragmatic Thinking and Learning it’s excellent!

Kindly cogs in unpleasant machines

Some of the most villified companies are poorly regarded because of the way they treat their own customers. Think about people complaining about AT&T’s service in New York City or people put on hold for hours by their electric company during a power disruption. Instead of treating these problems as real, telephone and electrical companies treat them as items in a queue to be dealt with as quickly as possible.

And thus, systems are set up that put a premium on throughput. Rewards are given to those who prevent customers from taking the time of the real experts who might fix a problem. Glib voice menus serve as a layer of indirection before you even reach a human. Service disruptions often bear a message tantamount to saying “we know we are not giving you the service we promised, buzz off and wait until we manage to fix it.”

Despite all this, sometimes you come upon a real jewel. Someone who really helps you, who cares about what’s going on. That special person who doesn’t care so much about their average call time, but who takes the time to get you to a happy place.

These are good actors working within a rotten system; kindly cogs in a vicious machine. I could call up AT&T and talk to any number of nice, well-meaning and empathetic people. Sometimes they are empowered and can fix the problem I face. Just as frequently, they want to help but the system they operate in prevents them from doing so, either because it would take too much time or because it is deemed too expensive to put the decision in the hands of those answering the phones.

When I describe them as cogs, it’s almost literal. Though manufacturing in the US is in serious decline, manufacturing-style management is not. Managers routinely and without irony describe people they might hire as “resources” that they can “utilize”. If there were a machine that could pop out customers whose problems had been resolved, managers would “utilize” those “resources” in the same way. Indeed, the majority of information systems attempt to do just this.

My point is that we regard a company like AT&T, Microsoft, Walmart, or Coca-Cola as a homogenous thing with its own will, priorities, and personality. But companies aren’t homogenous, because people aren’t.

Here’s to those kindly cogs. Thanks for making our interactions with these unpleasant behemoths just a little less daunting.

A quick RVM rundown

(It so happens I’m presenting this at Dallas.rb tonight. Hopefully it can also be useful to those out in internetland too.)

RVM gives you three things:

  • an easy way to use multiple versions of multiple Ruby VMs
  • the ability to manage multiple indpendent sets of gems
  • more sanity

First, let's install RVM:

  • gem install rvm
  • rvm-install
  • follow the directions to integrate with your shell of choice

Now, let's install some Rubies:

  • rvm list known will show us all the released Rubies that we can install (more on list)
  • rvm list rubies will show which Rubies we have locally installed
  • rvm install ree-1.8.7 gives me the latest release of the 1.8.7 branch of Ruby Enterprise Edition
  • rvm install jruby will give me the default release for JRuby
  • rvm use jruby will switch to JRuby
  • rvm use ree will give me Ruby Enterprise Edition
  • rvm use ruby-1.8.6 will give me an old and familiar friend
  • rvm use system will put me back wherever my operating system left me

The other trick that RVM gives us is the ability to switch between different sets of installed gems:

  • Each Ruby VM (JRuby, Ruby 1.9, Ruby 1.8, REE) has its own set of gems. This is a fact of life, due to differing APIs and, you know, underlying languages.
  • rvm use ruby-1.9.1 gives you the default Ruby 1.9 gemset
  • rvm use ruby-1.9.1%acme gives you the gemset for your work with Acme Corp (more on using gemsets)
  • rvm use ruby-1.9.1%wayne gives you the gemset for your work with Wayne Enterprises
  • rvm use ree%awesome gives you the gemset for your awesome app
  • You can export and import gemsets. This can come in handy to bring new people onboard. No longer will they have to sheepishly install gems on their first day as they work through dependencies you long since forgot about.

Some other handy things to peruse:

I also promised you some extra sanity:

  • RVM knows how to compile things, put Rubygems and rake in place, even apply patches and pull from specific tags. You can do more important things, like watch The View or read an eleven part series on pre-draft analysis for the Cowboys.
  • RVM lets you isolate different applications you're working on. Got one app that doesn't play nice with Rails 2.x installed? No problem, create a gem environment for that! Stuck in the spider-web of Merb dependencies? Isolate it in its own environment.
  • RVM makes multi-platform testing and benchmarking easy. You can easily run your test suite or performance gizmo on whatever Rubies you have installed.
  • RVM makes it easy to tinker with esoteric patchlevels and implementations. For instance, feel free to tinker with MagLev or the mput branch of MRI.

A couple other things RVM tastes great with:

  • Using homebrew to manage packages instead of MacPorts
  • Not using sudo to install your gems
  • Managing your dotfiles on GitHub

The imperfection of our tools

I enjoy a well-crafted application. I place a high value on attention to detail, have opinions on what design elements make an application work, and try to empathize with the users of applications I’m involved in creating. Applications with a good aesthetic, a few novel but effective design decisions, and sensible workflow find themselves in my Mac’s dock. Those that don’t, do not.

The applications I observe fellow creators using to create often don’t fit into their environment. They don’t fit into the native look-and-feel. They ignore important idioms. Their metaphors are imperfect, the conceptual edges left unfinished.

In part I notice this because as creators we tend to live in a few different applications, and time reveals most shortcomings. But in part, I notice this because the applications are in fact flawed. Flawed to the point, that you would think given my opening words, that I would refuse to use them. And indeed, I refuse to use many of the applications that others find completely acceptable for making the same kinds of things I do.

Increasingly, it seems the applications that people who create things live in offer a disjoint user experience. I’m thinking of visual people living in Photoshop or Illustrator or developers living in Emacs or Terminal.app. We use these applications because they best allow us to make what we want and get in our way only a little bit. But, it’s a tenuous relationship at best.

What’s this say about what we’re doing and the boundaries that we operate along? Would we accept the same kinds of shortcomings in say, a calendar application or a clock widget, if those were central to our workflow? That is, is there something about the creative process that leads us to accept sub-perfect tools? Is it inevitable that someone seeking to make new things will find their tools imperfect? Is the quest for ever-more perfect tools part of how we grow as makers?

I hate closing with a bunch of questions, but this piece is but an imperfect tool for discovering an idea.

Ed. Closing could use some work.

Warning: politics

Embedded within the migraine that is American politics are some very interesting ideas. Economics, markets, ethics, freedom, equality, education, transportation, and security are all intriguing topics. Recently, I figured out that the headache comes not from people or trying to make the ideas work, but in politics. Getting a majority of the people to agree on anything is a giant pain of coordination. When you throw in fearmongering, power struggles, critically wounded media, and the fact most people would rather not think deeply about any of this you end up with the major downer that we face today.

All that said, here are some pithy one-liners about politics:

  • If I were part of the Democratic leadership, I’d be wondering how you take the high road in a race to the bottom. And win.

  • If I were a Republican, I’d be wondering how to dig myself out of this giant hole I made by winning a race to the bottom.

  • If I were a libertarian, I’d be wondering how to convince people that the Tea Party is different from what I believe in.

  • If I were a leader of the Tea Party, I’d be wondering what I’m going to do when someone who claims to be a part of the Tea Party blows up a building or goes nuts with an assault rifle.

  • If I were a politician, I’d wonder how much I have to compromise my values and what I really wanted to accomplish but still get enough votes to keep my job.

  • If I were skeptical of climate change due to human activity, I’d be wondering how I’m going to find a spaceship, because this line of reasoning leads to the conclusion that the Earth is about to become very inhospitable.

  • If I were a nihilist, I’d wonder…nothing.

There, have I offended everyone?

Goodbye, gutbombs

Last March my wife and I joined a gym, started working out with a trainer, started trying to eat better, and thusly set out to improve our health. Amazingly, we’ve stuck with it (after two previous failed attempts in years past) and are both in much better shape than we’ve been in for quite some time.

One of my personal reasons for doing this was what I’d been hearing about the correlation between working out, eating better, and brain function. Lots of people who read way more into this than I do had been saying that if you eat better and exercise more, your brain will work better.

I’ve noticed this first hand. The day after my first serious run, my mind was in overdrive. I had lots of great ideas, I worked through them quickly, and I didn’t procrastinate when it came to exploring or realizing them.

Today, I had the opposite experience. I went out for a rather large Tex-Mex lunch. Lots of starch. I got home and took a nap, as is often my wont. Usually I wake up ready to get back to work after my naps. But today was different. My brain was thoroughly sluggish. My body’s energy was going towards digestion, not thought.

I guess this is something of a break-up letter for me. You see, I’ve long enjoyed the large, starchy lunch. But, I’m not sure I can put up with it anymore. If its a choice between starchy, tasty lunches and a high-functioning brain, I’m going to have to choose my brain.

Sorry, lunch-time gutbombs. We had a good run, but I’m going to have to quit you for a while.