Ask HN: When coding, how to do remember what you were doing the previous day?
67 comments
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…So glad you mentioned this! Back when I coded a lot more, I'd write a failing test with a note (e.g. "Fix date handling when converting from non-GMT timezones") letting me know where to pick up.
These days I keep a worklog for each day that I can flip through, and mark various items as TODO in the log. That allows me to track state over more days, which is useful when there are half a dozen projects to track.
These days I keep a worklog for each day that I can flip through, and mark various items as TODO in the log. That allows me to track state over more days, which is useful when there are half a dozen projects to track.
I do the same. Additionally, I'll generally write an unexecutable bit of code where I left off. If I try to start again the program will error out on the line I left off on.
Yea, this is definitely the way. Stop at a logical stopping point. Leaving at the point where a task or sub-task is completed ensures the next time you come back there's a logical next step for you to begin.
My current setup: I work in tmux (similar to GNU screen) on a server. I reattach to the session with `tmux a`, and detach with ctrl-b-d. This preserves my tmux windows between ssh sessions, and this captures my state of work where I stopped some code open, commands running, etc. I have command history and "go back" accessible in vim and my command panes. I find this is the best way to jump back in. I reboot weekly, after which I have to re-arrange my work area, but once a week is OK.
I find tmux much more effective for this than just arranging windows on my laptop, because ALL the tmux panes are work related, as opposed to windows on the desktop which get littered with email, websites, calendar, chats, etc. This is mentally hygienic for my productivity -- the terminal is where work happens similarly to how the bed is where sleep happens, so it is easy to get back into the flow based on the context.
I don't feel as productive and lose context a lot more when I had to load up an IDE each morning. If you have to use an IDE, I would recommend leaving it on overnight by hibernating the machine or similar, so you have all your code arranged, breakpoints set, navigation history/undo history etc. This helps me remember where I'm at when I start again in the morning. I'll even often leave the debugger at a breakpoint! I also recommend using the terminal within your IDE if it does not suck (I know it does suck in some IDEs). This allows you to keep all programming operations in one context similar to tmux.
I find tmux much more effective for this than just arranging windows on my laptop, because ALL the tmux panes are work related, as opposed to windows on the desktop which get littered with email, websites, calendar, chats, etc. This is mentally hygienic for my productivity -- the terminal is where work happens similarly to how the bed is where sleep happens, so it is easy to get back into the flow based on the context.
I don't feel as productive and lose context a lot more when I had to load up an IDE each morning. If you have to use an IDE, I would recommend leaving it on overnight by hibernating the machine or similar, so you have all your code arranged, breakpoints set, navigation history/undo history etc. This helps me remember where I'm at when I start again in the morning. I'll even often leave the debugger at a breakpoint! I also recommend using the terminal within your IDE if it does not suck (I know it does suck in some IDEs). This allows you to keep all programming operations in one context similar to tmux.
This hits on the head a broad pattern in my computer usage: never close something you'll come back to soon.
I've known many people who finish the workday by clicking Shut Down on their workstation, and start the next workday with a fresh boot. That is so alien to me; I click Suspend, so each day everything is exactly how it needs to be to continue working, including terminal output, running processes, open windows and their state, etc. This saves me time, and jump-starts my brain by basically loading in the swapped-out mental context I was in yesterday instead of reinitializing the same mental state from scratch.
I've known many people who finish the workday by clicking Shut Down on their workstation, and start the next workday with a fresh boot. That is so alien to me; I click Suspend, so each day everything is exactly how it needs to be to continue working, including terminal output, running processes, open windows and their state, etc. This saves me time, and jump-starts my brain by basically loading in the swapped-out mental context I was in yesterday instead of reinitializing the same mental state from scratch.
> I reboot weekly, after which I have to re-arrange my work area, but once a week is OK.
You may want to have a look at Tmux resurrect[0]
0: https://github.com/tmux-plugins/tmux-resurrect
You may want to have a look at Tmux resurrect[0]
0: https://github.com/tmux-plugins/tmux-resurrect
Thank you!
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.
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.
> Don't get to that point.
It should be added that just because you're "done" at 3:30, there's probably plenty to do. I spend the last bit of my day doing other things that are important such as checking email, responding to pings, writing documentation, updating tests, catching up with coworkers, etc.
It should be added that just because you're "done" at 3:30, there's probably plenty to do. I spend the last bit of my day doing other things that are important such as checking email, responding to pings, writing documentation, updating tests, catching up with coworkers, etc.
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.
Yes, this is a good practice whether you're leaving for the day or not. See David Allen's book 'Getting Things Done'. A central principle of it is: the place for your todo list is on paper (or some repository), not in your head. This clears your head for focusing on the immediate task at hand. So can be helpful for getting into a flow-state during the day, as well as between days.
Agreed. I gradually morph that to-do list into pseudocode and that into code, sometimes in a comment block.
When in the code and need to jump around different thoughts all in progress, I also tend to put "%%" and/or "%%$%" as a marker for "come back to this". (It helps that it doesn't compile, and works across platforms or different editors, so I don't have to change the habit over time.)
When in the code and need to jump around different thoughts all in progress, I also tend to put "%%" and/or "%%$%" as a marker for "come back to this". (It helps that it doesn't compile, and works across platforms or different editors, so I don't have to change the habit over time.)
I have a ten year old TODO text file which contains almost everything I have left unfinished. The top of the file contains the latest task I have to finish, and the details, including the device/machine involved, files, what I was doing, and what needs to be done.
When something of higher priority comes up, I enter that at the top.
When things are done, I add "DONE" against those tasks.
Once in a while, I clean up all the "DONE" tasks.
It is a mangled mess, but it has helped me survive for one decade now.
When something of higher priority comes up, I enter that at the top.
When things are done, I add "DONE" against those tasks.
Once in a while, I clean up all the "DONE" tasks.
It is a mangled mess, but it has helped me survive for one decade now.
I try to stick to the GTD approach and use a list with next actions for the projects, combined with a journal/lab-book for larger projects where I note thoughts, why did that, where, which folder, people, papers etc. That helps to continue after more than a few days (sometimes weeks or months).
Regarding implementation, I tried pen and paper/notebook, folders (hängeregister), git-repos for every project (even non coding projects) in gitlab with issues to keep track of todo's.
But for me, the best thing so far to implement GTD with a journal is a personal/private blog using a static site generator. Editing happens in Sublimetext, all under version control. I use Nikola because it's written in Python and easy to customize. I use a daily blog-post as inbox for all thoughts/notes/todo's during the day. And at the end of the day I write down what I did and what needs to be done tomorrow. And every project has it's own project-page with outline, milestones, journal, etc. From time to time, sometimes at the same day, sometimes at the end of the week I review and move content from the daily posts to their corresponding pages.
Regarding implementation, I tried pen and paper/notebook, folders (hängeregister), git-repos for every project (even non coding projects) in gitlab with issues to keep track of todo's.
But for me, the best thing so far to implement GTD with a journal is a personal/private blog using a static site generator. Editing happens in Sublimetext, all under version control. I use Nikola because it's written in Python and easy to customize. I use a daily blog-post as inbox for all thoughts/notes/todo's during the day. And at the end of the day I write down what I did and what needs to be done tomorrow. And every project has it's own project-page with outline, milestones, journal, etc. From time to time, sometimes at the same day, sometimes at the end of the week I review and move content from the daily posts to their corresponding pages.
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.
This may be a bit of a paradigm shift on the original question, but I’ve found that arranging my software and project in such a way that “cognitive overhead” is minimized will make startup cost extremely low.
If the code is very simple to reason about at a high level, you won’t need to remember many details. If your dev environment is stateless such that simply “opening the project” (for me, cd-ing into the project directory in my terminal) will automatically set up everything you need to start iteratively developing, you won’t have to focus mental energy on project setup.
This leaves you free to really only worry about the exact thing you were doing.
If the code is very simple to reason about at a high level, you won’t need to remember many details. If your dev environment is stateless such that simply “opening the project” (for me, cd-ing into the project directory in my terminal) will automatically set up everything you need to start iteratively developing, you won’t have to focus mental energy on project setup.
This leaves you free to really only worry about the exact thing you were doing.
If you are unfamiliar, I would recommend looking into 'test driven development', i.e. writing tests before you write the implementation, when applicable.
I find it helps clarify/organize and speed up my coding process, and makes it easier to write code even when not in a "flow" state. And it's much easier to, say, write a suite of unit tests in one sitting than to write a working implementation.
I find it helps clarify/organize and speed up my coding process, and makes it easier to write code even when not in a "flow" state. And it's much easier to, say, write a suite of unit tests in one sitting than to write a working implementation.
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.
I use Windows. I support Windows at work. I don't code. But I need to pick up one day where I left off the previous day like anybody else. My solution works on Windows, but should be easily portable to any other platform.
I have a batch file called remember.bat, stored in my %PATH% so I can call it from anywhere (I usually use the start menu run box). It simply ECHOes the time, date, and any command line arguments to a text file. Like this:
(First post. Sorry if the formatting breaks.) (edit: yeah, formatting broke.)
time /t >> %userprofile%\documents\notes.txt
date /t >> %userprofile%\documents\notes.txt
echo %* >> %userprofile%\documents\notes.txt
echo. >> %userprofile%\documents\notes.txt
exit
I also have a log viewer application called CMTrace.exe (from Windows SCCM) in my startup folder, pointing at that notes.txt file.
So when I log in to my computer, CMTrace tails the notes file, highlighting a bunch of key words in different colors to make severity more obvious.
When I need to add something to the list, I just start\run, type "remember whatever I need to remember" (without quotes) and the file is appended with:
06:47 AM Thu 01/14/2021 whatever I need to remember
If you want to view it live, you can use anything that can tail a file instead of CMTrace if you don't have access to it. Otherwise it's available to refer to anytime with your text viewer of choice.
If I need to remove something from the notes, I can open it in Notepad++ or whatever and save it, but I find myself leaving everything there for future reference.
I realize the post starts with "When coding", but I imagine this could work there, and I know it works elsewhere, so I figured I'd share anyway.
I have a batch file called remember.bat, stored in my %PATH% so I can call it from anywhere (I usually use the start menu run box). It simply ECHOes the time, date, and any command line arguments to a text file. Like this:
(First post. Sorry if the formatting breaks.) (edit: yeah, formatting broke.)
time /t >> %userprofile%\documents\notes.txt
date /t >> %userprofile%\documents\notes.txt
echo %* >> %userprofile%\documents\notes.txt
echo. >> %userprofile%\documents\notes.txt
exit
I also have a log viewer application called CMTrace.exe (from Windows SCCM) in my startup folder, pointing at that notes.txt file.
So when I log in to my computer, CMTrace tails the notes file, highlighting a bunch of key words in different colors to make severity more obvious.
When I need to add something to the list, I just start\run, type "remember whatever I need to remember" (without quotes) and the file is appended with:
06:47 AM Thu 01/14/2021 whatever I need to remember
If you want to view it live, you can use anything that can tail a file instead of CMTrace if you don't have access to it. Otherwise it's available to refer to anytime with your text viewer of choice.
If I need to remove something from the notes, I can open it in Notepad++ or whatever and save it, but I find myself leaving everything there for future reference.
I realize the post starts with "When coding", but I imagine this could work there, and I know it works elsewhere, so I figured I'd share anyway.
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).
Vimwiki. I keep a daily diary of what I'm doing, when I'm doing it. I use checklists to both note my next tasks and keep a record of what I did. At the top of every day, I copy over everything from the previous day, and remove the top level completed tasks.
My working memory is essentially non-existant, so this is necessary every day.
My working memory is essentially non-existant, so this is necessary every 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.
Not quite remembering last day, but I usually write out a list of what to do the next day. The effect is similar.
An old writer's trick: stop in the middle of a paragraph, or even a sentence. That way, there is something to do at the beginning of the next writing session, without having to think to hard about it.
An old writer's trick: stop in the middle of a paragraph, or even a sentence. That way, there is something to do at the beginning of the next writing session, without having to think to hard about it.
Use a screen recorder to record a 2-3 minute video of what you're working on and where you are going next.
https://www.loom.com is what I use.
It's a free, low friction service, just click a few buttons and you can record a screengrab with voiceover.
https://www.loom.com is what I use.
It's a free, low friction service, just click a few buttons and you can record a screengrab with voiceover.
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
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
I have my own personal document (any text editor would do) for notes attached to whatever I'm working on. What's on it depends on the task but usually, I write down all the things that need to get done and the status of where I'm at.
The notes I write aren't that specific to code though. Like, I'm not gonna write "I was looking at x file at code line y" but I'll write "Finishing serializer up" and any other notes that might help.
The notes I write aren't that specific to code though. Like, I'm not gonna write "I was looking at x file at code line y" but I'll write "Finishing serializer up" and any other notes that might help.
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.
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?
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?
I keep a Google Doc as like an infinite document for my work notes; every day I add a new bullet at the top with the day's date and write sub-bullets over the course of the day (work done or tasks Todo if someone's asked for something).
To remember what I'm doing I either look at my last commit or my staged file changes. I'm surprised to learn people are resorting to comments / broken code, tbh.
To remember what I'm doing I either look at my last commit or my staged file changes. I'm surprised to learn people are resorting to comments / broken code, tbh.
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.
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.
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.
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.
Also "split views", //TODO comments and focusing on one task at a time help a lot.
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.
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.
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.
Hibernate, so I don't need to spend time re-opening my IDE
If I'm in the middle of a larger task, add a failing unit test with a few thoughts about what I need to do next
If I've come to the end of a block of work, ensure that the top of my TODO list has an actionable, and quick item to start off with before I stop.
If I'm in the middle of a larger task, add a failing unit test with a few thoughts about what I need to do next
If I've come to the end of a block of work, ensure that the top of my TODO list has an actionable, and quick item to start off with before I stop.
I have a org mode file (which I edit in VS-Code) - I finish the day by creating some tasks for the next day.
Does an org document in VScode have any advantage over Markdown? Or does VScode have an org-mode extension?
Apologies, should have said I use an extension for org-mode:
https://github.com/vscode-org-mode/vscode-org-mode
https://github.com/vscode-org-mode/vscode-org-mode
[deleted]
Yes, 'break the compile' is one great way.
Another is not to keep going until you get to a neatly wrapped up stopping point. Leaving something partly done makes it fast to get back into the groove--just make it clear what's completed and remaining.
Another is not to keep going until you get to a neatly wrapped up stopping point. Leaving something partly done makes it fast to get back into the groove--just make it clear what's completed and remaining.
Fucktons of notes and having a To-Do list in high-level and low-level points of view. Detailing them with ETA, Deadlines, and intended effects on qualitative and quantitative metrics kinda makes them easier to prioritize, too.
Easy, at the top of every source file I worked on, I write TODO comments for the next day before closing everything and leaving. Also if I know it's likely that I won't return to a file on that day I do the same for that file.
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.
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
This is certainly not a full solution to reloading your mental context, but *persistent undo* is quite helpful.
After opening a project back up I just press undo a few times to see what the last edits I made were.
After opening a project back up I just press undo a few times to see what the last edits I made were.
Notebook by my side. Only way for me to remember. I also use it future todo.
Agreed. I use the Bullet Journal technique and find it very useful. Take notes, break projects down into components, and track your progressl
That and get religious about creating tasks/bugs for stuff you are not going to fix right now for team-level accountability.
Stone age tech: notebook and pencil write one item per line as I think of them and put a check mark on the left when it's done and a capital T when it's unit tested and passes.
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.
If I’m ready to commit, I look at my most recent commit notes. If I’m not, I either:
- recall by what was open last
- recall by hitting undo a couple times
- stash with notes if I worry that won’t be enough context
- recall by what was open last
- recall by hitting undo a couple times
- stash with notes if I worry that won’t be enough context
I let my tests serve as an outline of what I need to do. That way I can recall from the previous day what I was working on and where I need to pickup.
I try to commit my code granularly and leave myself some comments. I check my commit logs to figure out where I was to quickly get back to it.
Not recommended but I tend to think about the problem I'm solving during off hours. I also constantly take notes about next steps
Paper pad with notes or working on something interesting enough that I think about it after I’m done for the day.
I always leave a broken test so on the next day, when I run my tests, I know exactly what to do next
I write myself a note on a post-it as a reminder when I feel like I might need a reminder.
1 fps screen capture which i can rewind and check back on anytime.
I usually keep a running "to-do" list with nested subsections as needed
Tests
todo.txt on the desktop
For this to work, the next day I need to be able to remember what I was in the middle of before I left.
What techniques do you use when coding, to make sure you can pick up from where you last left off (without spending half an hour trying to get back into the flow)?
Personally I write "here" in the IDE to break the compilation, so the IDE will bring me back to that place in the code when I next try and compile. Sometimes I also add a line or two describing the very next thing I want to do e.g. "finish this off and then maybe move it to the viewmodel" etc
Anyone else?