Everything is too hard.

Google Keep on the web is frustrating — sometimes I go to the Keep window I keep pinned, and it turns out that I’m in a view that doesn’t let me take any single action to get to a “create note” flow. Usually it happens when I’m either scrolled into further down my stack of notes, or when I have a note I’m working on. This feels, frankly, infuriating to me. There is no way, I feel, this is the right UX for this; when I get to Keep I’m usually in quick search of what I want, which is one of two actions:

  • Find, and read, a note I’ve written.
  • Write a new note.

Usually I’m in a rush: I’m in the middle of something and I need a quick note I’ve written in the past at hand to accomplish what I now want; or I have just thought of something and I want to write it down because I fear I’ll forget (either it’s a number, or perhaps a chain of thoughts that I feel may evaporate any minute now).

Keep fails at both flows in a sense. For the writing action: first, what I’ve already mentioned — in several contexts, there’s no simple way to get to write a note. I don’t want to have to deal with extra actions like scrolling and searching for the ‘Take a note’ text box, or pressing escape to exit ‘Search’ when I’ve left Keep on the Search screen.

For both, a single failing: the fact that, being two use cases that I think about on the same level (I don’t think of one of the use cases as most important; either both work, or the product is useless to me, at least in the long term) the abstractions that call them out are different in hierarchy. Search is usually at the top of the UI elements, while write is a similar widget just below. It would probably be OK if it was a different UI element, say a ‘+’ to compose — like Gmail does. But being the same kind of element and prioritized lower in the UI just doesn’t make a lot of sense in my mental model of the app. I say this all not to shame the Keep engineers. Writing software is hard. Let’s assume for a minute that my gripes are representative of a significant fraction of the userbase; if it’s not mine, there are others. The engineers pretty likely have a good feeling for what’s wrong, and in the back of their mind they dream of the time when they can just go ahead and fix it. Make the app a relatively seamless extension of your mind, in a sense. But there’s never enough time — doing anything is hard, any UX or architectural change probably takes them not just 10x but perhaps 100x of the effort they feel it should take.

Most software fixes are easy conceptually, but hard in practice. Change something into something else. Fix the callers. Fix the tests. Perhaps you need a refactor — that’s fine, our tools nowadays can help there. But they can’t help with writing most of the actual new logic. Some day they may — when that happens, programmers will be able to focus on different things.

But wait, actually, some of the same issues are also present in mobile and they should fix that also. Now that’s a different team, perhaps, or it needs the support of another team — perhaps not for a UX change, but for most of the architectural changes for sure. Perhaps the right way of enabling a user to find their most common notes requires a new remote call to suggest the right notes given the time of the day, and the users’ usage patterns. And so it goes.

So the Keep engineers are likely trying to do the right thing. And most engineers around the world are. They just don’t have the humanpower, or the tools.

ML could help here. More ML in software development tools could make some or most of the steps involved in shipping a fix automatable, in the best case. What

What would happen if ML could tackle full on programming? Programming would probably need to be redefined, like it will happen countlessly as ML infringes on the field of human thought, and human activity; it would cease to be about C++ or Java, and become more and about reporting the right bugs and the sending right feature requests to the model. Which then does the “mindless” thing — write the new method, fix the tests, submit the change and go through the process to ship the change through the release process to production. Perhaps even monitor how well it works once it ships. And even if it didn’t do everything in this list it would add value; these may turn out to be iterative improvements that happen as we progress in this field.

So, I’m not an expert in tooling, but I’m sure researchers are working on some aspects of these hypothetical toolchain that will get us there; and thinking about the others. I don’t have any particular insight into the problem; but I wanted to think a bit about how some of the steps in this process could work.

How could a next generation code writing assistant look like? One idea might be to augment test-based development; you perhaps write the function signature, then you write tests for it, and of course assert what valid input looks like. Sounds similar? Expected outputs in unit tests sound like a kind of labelling. A generative model (similar to GPT-2) could presumably be trained on a huge amount of code, and potentially learn the utterances that are most likely to yield the expected output. A programmer could probably look at failed solutions and give feedback on high level issues to be fixed, or thing to be tried. For example, write more code involving a variable (that the programmer can intuit needs to be transformed). Or, perhaps, add some intermediate state that the programmer knows should be there (do something for every element in an array; or define a variable with some well thought out name) to lead the model along the right path.


Comments powered by Disqus