Another two months to go and I will have finished all of the taught modules for my master's degree in HCI. Next up — the dissertation. All I need is a topic.

Initially I thought about somehow combining HCI with linguistics or NLP. For example, as I learnt from @karlsutt (a vocal advocate of functional programming), developers won't realise how hungry they are for accessible error messages until they've worked with Haskell or Elm, a functional language that compiles to Javascript. In addition to (supposedly) eliminating run-time exceptions, Elm aims to make the programmer happy when debugging by producing more comprehensive and “human” error messages than what we've so far been exposed to.

Putting such claims under scrutiny and conducting a more general study of what makes the difference between a user-friendly error message and one that is frustrating would certainly have been interesting. But looking into it further, the common ground that error messages share with linguistics on the one hand and HCI on the other is too far-fetched to justify.

Luckily, the idea led to a whole new area of potentially impactful research – usability for programmers. This, I think, has an almost romantic ring to it. If UX is all about putting the layman front and centre when designing technology, then what of the neglected developer, deciphering compiler errors, trying to make sense of git rebase, and battling the RSI that gets worse every time they must reach the tiny ESC key with their pinky because Caps Lock is already remapped to Ctrl to make Emacs keybindings more ergonomic…

As it turns out, the programmer is not as neglected as one might think. An initial search for “debugging strategies user study” led to a range of specialised research from copy & paste practices to facilitating feature location in large codebases, accessible directoy structuring, automated debugging tools, as well as more social issues such as code ownership and managing implicit knowledge.

I have narrowed the choice down to four areas:

1. Causes behind copy & paste errors, and tool design to prevent them
2. A review of debugging strategies: from fault identification to correction
3. Visualising git repositories to facilitate comprehension of version control
4. Feature location in large/unfamiliar codebases

One of these will become my breakfast, lunch and dinner for the better half of the following year!

A note on methodology

In the area of programming HCI, it is not only the research itself that can make a contribution to the field: adapting research methods to match developer working habits and evaluating their use has potential value, too. Ethnographic studies may have their roots in the African bush where missionaries and anthropologists dutifully noted down cultural peculiarities, but they have been relatively successfully adapted to fit user research in HCI. But where the user is a programmer, many of the best practices for conducting usability studies may well blow up in your face. For example, how do we interpret eye-tracking data when a developer is scanning code? Is it even significant? What about qualitative data from a think-aloud session with a solo programmer? Will the nature of a think-aloud study not transform the session into what is essentially pair programming? And don't even get me started on diary studies… Whatever the eventual topic, it'll be a fun challenge coming up with the methodology.