I always try (not always successfully) to stop what I'm doing when it's time to go home. (If instead, I try to finish what I'm working on before heading home, sometimes I'll accidentally still be working 3 hours later).<p>For this to work, the next day I need to be able to remember what I was in the middle of before I left.<p>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)?<p>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<p>Anyone else?
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:<p><pre><code> 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…</code></pre>
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.<p>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.<p>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.
My bits of advice:<p>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.<p>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.<p>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.<p>4. Break tests. If you know you need to finish something, write a test for it that doesn't work.
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 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.<p>When something of higher priority comes up, I enter that at the top.<p>When things are done, I add "DONE" against those tasks.<p>Once in a while, I clean up all the "DONE" tasks.<p>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 <i>next actions</i> 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).<p>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.<p>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 <i>inbox</i> 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.<p>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.<p>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 <i>before</i> you write the implementation, when applicable.<p>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.<p>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:<p>(First post. Sorry if the formatting breaks.) (edit: yeah, formatting broke.)<p>time /t >> %userprofile%\documents\notes.txt<p>date /t >> %userprofile%\documents\notes.txt<p>echo %* >> %userprofile%\documents\notes.txt<p>echo. >> %userprofile%\documents\notes.txt<p>exit<p>I also have a log viewer application called CMTrace.exe (from Windows SCCM) in my startup folder, pointing at that notes.txt file.<p>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.<p>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:<p>06:47 AM
Thu 01/14/2021
whatever I need to remember<p>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.<p>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.<p>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.<p>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.<p>An old writer's trick: stop in the middle of a paragraph, or even a sentence. That way, there is <i>something</i> 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.<p><a href="https://www.loom.com" rel="nofollow">https://www.loom.com</a> is what I use.<p>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)"<p>I separately keep a TODO file with the list of next major task items, and I break them down into subtasks if necessary.<p>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.<p>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.<p>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).<p>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 <i>not</i> 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.<p>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.
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.<p>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<p>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<p>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.
Yes, 'break the compile' is one great way.<p>Another is <i>not</i> 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.<p>After opening a project back up I just press undo a few times to see what the last edits I made were.
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:<p>- recall by what was open last<p>- recall by hitting undo a couple times<p>- stash with notes if I worry that won’t be enough context