Ready To Hand

On the necessity of Google when coding.

Heidegger wrote, interminably and in German, of the difference between objects that are ready-to-hand and present-at-hand.  The difference he saw (and I make no apologies for drastically simplifying the philosophy to let me make my point) is that the latter is whatever it is we’re thinking about, and the former are the things we use without thinking about them.  For example, right now, I’m thinking about how to construct an absurdly overwordy sentence to make a simple point and therefore sound clever (present-at-hand) but I’m not thinking about the keys on the laptop, or the various decorations around the Semagic window in which I’m typing.  Sure, they’re there if I need them, but they’re not the focus of my attention.  They’re ready to hand.

Good IDEs follow certain consequences of this principle, either through design or heuristics.  For example, Microsoft IDEs all now use tooltips to popup little bits of information as you code or debug.  It’s surprising how often the information displayed follows one’s line of though.  I type the open-bracket for a method call and lo! a list of arguments pops up just as I start to try and remember the exact order of them.  What I’m focused on changes as I work my way through code; from high-level design through the construction of the actual logic to the contracts for calling library objects.

Of late I’ve been spending way too much time in Eclipse – and here I have to pause and say that it’s caused me to reconsider a whole bunch of opinions I had about large Java programs.  In a good way.  Last time I tried out Java-based Java IDEs,  they were vast and cumbersome beasts that took hours of CPU time, megabytes of RAM and whole swathes of swapfile to even get to the point of starting up.  And when they did run, they looked awful and had interfaces designed by the Marquis De Sade.  It was a relief to run screaming back to the simple comforts of vi (and that’s not a phrase that you hear too often) and the command line.  Eclipse is different.  Yes, it probably does take up many system resources and it’s just that the machine I use is a damn sight more powerful.  But in both form and function, it’s a very well-designed environment.

Something I like about it (and it’s not a unique feature) is the way that different elements can be linked together.  Change the file you’re viewing, and other windows all quietly update to reflect that new focus.  Shift thread in the debugger and there’s that same ripple of change as everything around shows you information related to it.  Lovely.  Yet it only works on so many levels, and there’s one level that’s missed.  Google.

I was speaking earlier this week to a developer who’d been struggling with an obscure problem (in Python, as it happened).  Eventually, I asked him if he’d Googled to see what experiences others had had.  His reply was interesting – “I don’t really do that, I prefer the manuals”.  I find that an odd position to take.  Nowadays, when I’m looking at a new area of some language or development, one of the first things I’ll do is fire a few queries at Google to see what others have to say.  Take, for example, the creation and use of Images in J2ME/MIDP 1.  It took around three minutes to find several discussions of what could and could not be done (and a few rants about how brain-dead the design had been, but you got to work with what you have).  Sure, I could have inferred it from reading the API docs, but what I wanted was real humans writing about what they’d found, in language that makes sense to me.  Coder speaking unto coder.

So that’s what I want an IDE to have, as well as the type hierarchies, the file lists, the error messages and the stacks of cryptic toolbars.  A Google window that, quietly and without taking too much of my CPU or bandwidth, looks up comments from, say, (or comp.lang.python, depending on file type) that relate to whatever-the-hell I’m working on.  Sure, it’s a whole different class of problem from automagically doing content-sensitive help, but the team who can solve it would be rich in kudos owed by developers all over the world.  The actual coding is left as an exercise for the student, naturally…

Google.  The missing manual for much of what I do.


4 thoughts on “Ready To Hand

  1. standing on the shoulders of giants…

    Particularly in the area of crawling up the learning curve of a new technology, someone else’s experience crawling up the same curve is very valuable. Doing without the net is outright wasting time.

    When interviewing people for developer jobs, I have a number of questions that I don’t expect the candidate to be able to answer off the top of their head – I want to see what resources they will look for. Answers like “I’d start with the man page for ___” or “google for (phrase)” – the kind of thing that shows that they know where they’re *going*. (Sometimes they get handed a laptop with the man page showing šŸ™‚ Knowing when “look it up in Stevens” is the answer is good too, though.

    The taskbar/IDE you mention reminds me a lot of the Remembrance Engine, a tool for emacs written close to a decade ago by Brad Rhodes (one of the Wearables dudes) that keeps a few lines of search result for the most recent thing you’ve typed in emacs. It was originally based on a local index, not a remote one… there’s some expense to doing it remotely but maybe that’s tractable these days – 1000 queries/day via the google API is less than 2 per minute in a 10 hour day, but that’s not an unreasonable rate – even “only search when idle” might be enough to make it seamless…

    • Re: standing on the shoulders of giants…

      Interestingly, there are two Eclipse plug-ins for Google, but all they do is provide you with the results of a manual search in a View. Given that the Eclipse window is already somewhat overburdened with multiple panes, I’ll keep my Googling to Opera for the moment. But I like the remembrance engine idea; the extra-Interesting angle would be how one made it search on relevant stuff when you’re writing code. Obviously the variable names and keywords wouldn’t make much sense, so it’d have to be the API… now there’s an idea – a list of links to the API docs for any method call, class etc within, say, five lines of the cursor. Hmm.

  2. hmmm…

    It would be interesting if collaborative documentation annotation was availabe in a IDE. A little more structured than Google, but still reflecting shared experience. — Ian B

    • Re: hmmm…

      One thing I sadly miss in Java (and which I had begun to take for granted in Python) was docstrings; the availability of a nice, human-readable explanation of a method as soon as I hit the open parenthese (is parenthese a word?). A link between identifiers and some type of documentation would be good – leave it to Guido to think of putting it in the damn language…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s