The art of making a useful todo list

I have a tenuous relationship with todo lists. Rather than helping me focus on getting stuff done, they usually only give me something to tinker with and feel better about having slightly mitigated my procrastination.

I’ve used Kinkless, OmniFocus, and TaskPaper. The latter is helping more, due somewhat to its more spartan nature. But mostly, I’m simply wiser and more pragmatic about the extent to which a todo list app can improve my life as the years have gone on.

In that wisdom, I’ve eschewed working from my todo list much lately. Instead, I’ve just glanced at it a few times a week to make sure I’m not forgetting something crucial.

For no particular reason, I went back to working from a list last weekend. To my surprise, it worked out for the better. Things got done, a feeling of accomplishment was achieved, stress levels were down, greater relaxation was had.

I suspect this success was due to a confluence of factors:

  • I made sure my list was minimally aspirational; everything on the list was something I could achieve in less than an hour
  • The list was focused on what I need to accomplish; if something was nice-to-have, I did it in the rest times between working items on the list
  • A little bit of novelty can’t hurt; working from a list after a few weeks not doing so is perhaps just different enough to yield temporary productivity gains

All that said, I’m starting to think there’s an art to making one’s list of things to do on any given day. Something that is achievable, but moves the ball. Something not too aspirational, but worth doing. Fresh, but with some long-standing items that feel good to knock off.

Perhaps a good todo list is equal parts excitement, tedium, and accomplishment.

Posted in Expanded ideas | 1 Comment

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.

Posted in Code, Expanded ideas | Tagged | 6 Comments

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.

Posted in Code, Expanded ideas | Tagged | Leave a comment

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.

Posted in Code, Design, Expanded ideas | Tagged | Leave a comment

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!

Posted in Code, Expanded ideas | Tagged , | 1 Comment