> Why is it so hard to see code from 5 minutes ...
# linking-together
i
Why is it so hard to see code from 5 minutes ago?
A study found that Java developers backtracked every 6 minutes, meaning they reverted their code to a previous state. These undo actions come in bursts and are often followed by successive redo actions. In fact, one participant in a different study used undo/redo 40 times in 5 minutes! When asked why they did this, they revealed they were trying to view some intermediate state of the code in the middle of a change. Why is it so hard to see code from 5 minutes ago while in the middle of a change?
The author later presents a prototype named Yestercode
It lets you swipe through your code history on a timeline, much like you would a YouTube video. As you make edits, it aggregates them and puts a notch on the timeline for that version. You can then use the timeline to go to a previous version, giving you a side-by-side view with the current version of the code. The previous version is read-only, but still allows copying and pasting from it. It also shows annotations so that you know what has been changed in later versions (much like a diff).
https://web.eecs.utk.edu/~azh/blog/yestercode.html
😎 1
💯 1
👍 1
I'd be curious to know how many programmers don't ever hold down on undo to roll back a few hundred changes, do something, and then redo back up to the present. I find myself doing that at least once every few months, and I've heard other folks anecdotally talk about doing the same.
💯 3
f
Yeah, bulk undo & redo happens every once in a while. Though mostly I try to keep commits and small and use VCS diffs, but when that fails, I'm back to hoping I haven't messed up my redo stack somehow.
1
a
I don't think I've ever done that, and had no idea it could be widespread. Version control actually does (mostly) solve this problem for me, because I don't feel shy about committing every few minutes if that's what it takes. I do however look at my current git diff a lot, and diffs of other recent changes pretty often. It's true that it's still a pain to copy-paste out of history or otherwise partially restore it. The UI this author proposes sounds neat, but only if it transparently works with (at least) git.
k
As an anecdote, I spent some time yesterday yet again trying to make sense of http://paulgraham.com/bel.html. The sources are lots of tiny functions. But there's tons of calls between functions, and I'm constantly yoyoing between them. One of the things I want to enable in my project is allowing functions to be moved around independent of each other, so that I can move related functions around for the duration of a session. Kinda like Tiddlywiki (cross-link https://futureofcoding.slack.com/archives/C5T9GPWFL/p1613629318245700) I also recall that the original Light Table demo did this really well. I think such a feature would help here?
👍 2
g
i’m working on this problem in the context of web browsing. i genuinely think scrolling is a ux antipattern (at least most of the time) and the times i end up needing to undo, whether on git or via keyboard, almost always boil down to switching assumptions about the code i wrote that has just moved out of view. @Kartik Agaram you might be interested in the berrypicking search strategy literature
💡 2
👍 1
j
This particular undo/redo behavior is foreign to me. I like the slider + diff interface, though. 🙂
🤯 1
o
I find this discussion interesting, because it brings to light the complexity of the timeline of programming activities. The most obvious incarnation is the git record: git commits, pushes, merge requests, issues, etc. But this undo/redo thing used by some programmers and not by others shows that it is complicated and maybe there is something missing in our tools or in our workflow to fully grasp this "code history". I also like the slider idea!
And as a side note: it is one reason I like CRDTs, they can bring this kind of timeline functionalities easily.
w
It's a matter of scale. Undo-redo for things I was doing today. Git for things we have been doing over time.
2