Ask HN: When coding, how to do remember what you were doing the previous day?

I leave TODO lying around about what I was going to do next (clean these up before merging obvs), and also take actual hand-written notes about what solutions I'm thinking about. I tend to spend 90% of my time programming thinking, though.. once I know what I'm going to write it just comes out easily.

Typically I have a little to-do list on paper where I write down what needs to be done to implement a certain feature. I stike out the things I have completed and add new items on the go. Sometimes the to-do list is ordered (eg. when implementing a step-by-step algorithm); most of the time it is just a few unordered items. When I stop in the middle of such an item, I typically use the same technique as you: I add an invalid line of code, probably with a small note in the source code.

I leave the IDE, terminal and browser window open and send my laptop into hibernate. When I start it up again this context usually is sufficient to pick up where I left.

Personally I have an opposite problem of thinking too much about work after hours, but in case I really need to remember something it is written into notepad or note taking app. All modern text editors after introduction of Sublime Text (I use VSCode) have persistent sessions in settings, so I just keep lots of tabs (like in browser) and clear them after feature merge.

A good old paper TODO list. A plain text file works well too, and can be passed around in repos if you're working on different machines. I plot out everything I need to do up front and then get to work, adding more if necessary.

I typically leave something broken like you described. Either something it can't compile, or something simple like a test that isn't passing yet.

Paper pad with notes or working on something interesting enough that I think about it after I’m done for the day.

If it's a small project, usually I'll just leave my notes in the readme, or I'll litter TODO comments in the code. If it's a work project I'll usually put those notes in the Jira or Trello ticket

I create a compiler error where i left off.

I have a org mode file (which I edit in VS-Code) - I finish the day by creating some tasks for the next day.

I typically combine a TODO list with an overview of my (next) high-level steps in the flow that I had in mind to implement/work on. Also noticed that typically, after a day/night of rest, your thoughts get re-aligned and you might even come up with a better approach for one of the problems you encountered.

Notebook by my side. Only way for me to remember. I also use it future todo.

My bits of advice:

1. Don't get to that point. Don't back away from the keyboard when the clock strikes 5; move away from the keyboard when you're at a natural stopping point. If that point is 3:30, and you know that the next block of work you'd like to do is going to take you three hours, don't start it. Commit, push, and consider yourself done writing code for the day.

2. I keep a journal of what I do throughout the day. This probably is at a higher level than what you're looking for, but occasionally I'll post links to github with the file and line number where I left off.

3. Sometimes, I don't commit everything; hopping back on in the morning, a `git diff` shows me what I'm working on. This obviously doesn't work if you've changed a thousand lines, but that goes back to point 1 - have reasonable stopping points.

4. Break tests. If you know you need to finish something, write a test for it that doesn't work.

I always leave a broken test so on the next day, when I run my tests, I know exactly what to do next

I create checklists in the Trello card. Before I start on a task I have to mentally walk through it, which among other things can aid in estimating how long it will take.

I always write a commit and push it before I stop for the day, even if I'm in the middle of a complex refactor. If it's not a complete commit, I make sure to note that in the commit message so I can rebase it.

When I get back to work the next day, I look at the output of `git diff @~` and I'm back in the flow of things within a minute or two.

todo.txt on the desktop

For coding or any other project, I keep a running note called "Where I Was." Before putting down the project, I add a timestamped note that's as detailed as it needs to be. I find that this helps swap back context quickly, and it also has the benefit, for me, of swapping the project out! Clearing my mind like this helps me focus more on whatever I'm picking up, too.

I literally write "// TODO: YOU ARE HERE - (Summary of next tiny task)"

I separately keep a TODO file with the list of next major task items, and I break them down into subtasks if necessary.

This allowed me to do a side project in 15-minute chunks on my train ride to and from work for a year

Standby if it's really necessary and I do a lot of git commits that I squash later. Also I create notes where I keep track what I do, so I can present that in the daily meetings.

But usually, especially if it's complex, I enjoy the clean state. If it's too difficult to pick up later, then I ask myself: did I really automatize the things that should be automatized e.g. with a script or makefile? Is my project/code navigatable?

One idea out of many (many have been mentioned by others already): I set linter to always report failure in CI when TODO or FIXME markers are found. So my PR never gets green until I fix them all. I place o lot of such markers if I know that I will not finish in a given focus block (doesn't have to be an end-of-business-day).

Besides the compiler breaking comments, I also keep a personal "scrum board" of post-it notes on my desk where I write down every thing I would otherwise need to keep inside my head. This also greatly helps in reducing distractions like getting sidetracked into other bugs when working on a feature. You could do this with a file on your computer as well, but having something physical puts it more in your face and at hand is my experience.

Long ago I was reading about Ernest Hemingway's approach to dealing with writer's block and one thing he said has stuck with me and proved quite successful for both "coder's block" and remembering where I left off from the last coding session:

  I always worked until I had something done and I always stopped when I knew what was going to happen next. That way I could be sure of going on the next day…

I actually find it kind of helpful to not try to finish at the end of the day. When you're sort of in "implementation" mode, it's easy to get back to where you were.

After an hour of cleaning up loose ends, it can be nice to take stock and replan the day. While it can feel nice to finish a commit or model at the end of one day, it can actually lead the next morning to be unproductive.