I noticed that when refactoring you start building a stack of tasks that appear as you go along, sometimes you follow each task as it comes (breadth first) and some times you take notes or try to remember the next tasks to tackle later (depth first), is this specific to the way we code or general to coding (and maybe general to other activities), if so, what kind of tools would help keeping track of those task stacks (say it 10 times fast :P), or being a little bit more ambitious, what would those tools look like if they were builtin into our programming environments. Another interesting facts is that the activity as a whole is not reflected in my commits, I could create a branch and merge it to signal a complete activity, but each commit and their relations do not reflect the reason of the changes.

I use comments starting with

#!!

. For bigger refactors, I do end up with a bunch of commits that I merge into the main branch at the end. (I'm into true history rather than the rewriting that git allows.)

I like some parts that intellij has - like back navigation that really goes to the previous line, auto refactor which shows you where stuff is getting refactored too and similar. I’d love to have a dependency graph - I click show usage graph and it shows a graph of classes using it.

This somehow sounds to me like if you solve this problem, you’ll have solved structured editing along the way too. They seem related in a way, and I would consider structured editing the easier one of the two.

When doing bigger refactoring in dynamic language (Javascript), I normally end up doing a lot of searching around to find all the affected parts, and I write them down in a checklist to be able to track them. I do this in mostly BFS manner. Then, refactoring itself I do in more of a DFS manner, meaning I follow the checklist but I also dig deeper when I realize for certain item that there is more work to get done. Finally, if code is well tested, I expect broken tests to further guide me and warn me about all the places that I missed. If it is not well tested, well then it comes to manual testing of course, and hopefully I add some missing tests on the way. That said, I just recently switched from JS project to Haskell project, and experience is very much different. I don't have to do so much of investigating and thinking, I just start with one change and let the compiler guide me -> when I am done with fixing all compiler errors, I am mostly done all together + I have a good idea of all the affected parts (I don't need to search through the codebase that much). Then there are tests again to check the logic is functioning ok (not covered by type system), and that is mostly it. What do you mean by activity as a whole reflecting in commits: is that in case where you did the change through multiple commits and want it to be obvious they are all part of that change? Personally, I always create new branch for new "feature/activity", and when I am done, I squash all commits into one commit and rebase that onto master, often with github issues number included in the commit message. If feature/activity is bigger and it makes sense to keep it split into multiple commits (does not happen often to me), I still just rebase it into master - usually commit messages are descpritive enough to make it obvious what is the relationship between these commits. I guess you could prefix all of the commit (their messages) with same prefix, smth like issue number of feature name, to make that more obvious if really needed?

@Stefan yes refactoring is a good perspective on structured editing since the goal is to leave one thing (the behavior) the same while changing another (the representation). Leads to good questions, fundamental ones, "if it's going to work the same, what difference does the factoring make?" Right now I'm in the middle of a big refactor where a bunch of long lived objects are used in a calculation requiring a lot of temporary data, which was attached to the long lived objects meaning that they end up containing both the long-lived data and the transients together with code to ensure that the transients are reset, remain consistent from one calculation to the next. So in this case, the life-cycle of objects motivates the refactoring. We end up with more classes and a bunch 1-1 relationships, but the important difference is that one of those 1s is short-lived.

@stevekrouse talked on the podcast often about source control where you created branches for each of the changes you wanted to make and used the repo history as your task manager. This is all I see in written form, so I guess most of his thoughts are in his status update episodes.

Yes, I recall that episode. Having todos integrated with source control makes a lot of sense. We have issues integrated, but it's not quite the same.

this discussion makes me crave something between google docs and notion for code—a kind of illuminated manuscript on the code itself that can be collected into a master list with hyperlinks

Late to the party but would a 'bookmark' type feature work? E.g. you bookmark a line of code and even attach a note if you want. Later you can look at your list of bookmarks and jump to one to start working on it.

yes, adding marks with descriptions and tags would be useful, also if they can be grouped/sorted by file, tag and time