7 ms·

How to return to the flow faster

330 points by ribtoks 7y ago

Jeff_Brown 7y ago
In a nutshell: Know your goal, know what just happened, know what to do next. Maybe obvious, but I agree, critical, and a good thing to make explicit to oneself. The author presents a lot of seemingly complex tools for this. Mine are, I believe, simpler -- a TODO list in .org mode (goal and next), and git log (for what just happened, always with --name-status to show what files were affected how, and maybe with -p to show the diff). But you could use anything.
- ribtoks 7y ago
  Sure, but whenever you feel like you have an idea, you have to open your TODO list in org mode and update it. Also when you finish your intermediate goal, you have to again go to your file and mark item as done. In my case when you remove the comment right in the file you're working on, the task gets closed. Simple automation.
  - bcrosby95 7y ago
    It doesn't need to be a specific TODO file. I have a dev log in org mode. Any thoughts about what I'm working on go there. Including TODOs. It's always open, so there is no open/save/close process. Of course, I have to update it. But it's just one more file that gets updated. It's not onerous. Plus, I'm not destroying documentation about my development process. I have used this method since I started developing professionally 15 years ago. I can go back over a decade and look into why I did certain things for a piece of code and how I decided to break the work apart.
    - na85 7y ago
      Wow, how big is your dev log file?
  - WhatIsDukkha 7y ago
    It's pretty trivial to keep an open "project.org" buffer open for whatever project I'm working on. This is pretty natural in emacs but sometimes vim users aren't as confident with tabs or buffers. There is also https://github.com/alphapapa/outshine https://github.com/alphapapa/outshine Which gives you "full" orgmode in comment sections of your normal source code (haven't actually tried it myself). Overall I think you are on the right track with your goals but, yes, orgmode does a great job of solving them already with a bunch of additional features too.
    - ribtoks 7y ago
      First of all, the buffer will be too small for all tasks created on a branch and you don't want to have this buffer big, unless you have 2 monitors and have Emacs frame with this buffer opened for a half of it. Also this process is not automatic - you have to navigate to the buffer and close the task when it's done. Also from the that buffer it's impossible to sync outside (GitLab/GitHub) or share your tasks with a team, what is possible with Kanboard if it's running on DigitalOcean/Heroku or simply synchronizes with GitHub.
      - merlincorey 7y ago
        If one really wanted to do it all in emacs' org-mode but also have it be automated and sycned with the code, I believe the solution would resemble something along the following lines: Literate Programming in the Knuth sense with org-mode file using tangle[0] blocks holding the source code which can be used to generate and build the project, and a combination of regular emacs lisp code and some org-mode evaluated emacs lisp[1] to do whatever automation is needed. Now the TODOs can be in the org file, which contains the source, and may also have a reference (automated) to the TODO, which when closed with the regular org-mode command (and is generally only two key chords) will remove the comment as well as update your agenda, calendar, kanban, etc. [0] https://orgmode.org/manual/tangle.html https://orgmode.org/manual/tangle.html [1] https://orgmode.org/manual/Evaluating-code-blocks.html https://orgmode.org/manual/Evaluating-code-blocks.html
  - Jeff_Brown 7y ago
    If all my open problems could be localized in a single place in the codebase, I might indeed keep all my todo items as comments. But sometimes they span a lot of the code. The organizing principle of the todo document is problems. The organizing principle of the code is something else -- control, data. Perhaps ideally they would align, but in my experience they don't.
    - ribtoks 7y ago
      The point of todo comments is that they are written across all your codebase and the system collects them and visualizes without manual intervention.
      - Jeff_Brown 7y ago
        Oh. That does sound pretty nice.
- dfsegoat 7y ago
  Apologies for the ineptitude: What is .org mode for a TODO list?
  - dmamills 7y ago
    https://orgmode.org/ https://orgmode.org/ should help :)
- wpietri 7y ago
  One addition I'd make to this is unit tests. I try to stop with a failing unit test, which gives me a really obvious place to start when I pick it up again the next work session.
merlincorey 7y ago
The author found they needed a terminal replacement to `gitk` and they chose `lazygit`, but I would also like to recommend `tig`[0] as a commandline git browser. The mentioned kanban software, `kanboard`[1], is super easy to setup and use -- I did a survey of about 10 self-hosted kanban software tools and this was definitely a front-runner in terms of overall simplicity and ease of setup and use. I did not review the plugin architecture at the time, but glad to hear that it is fairly straightforward. [0] https://jonas.github.io/tig/ https://jonas.github.io/tig/ [1] https://kanboard.org/ https://kanboard.org/
cookingrobot 7y ago
Interesting approach. What would you think of having it sync the other way as well - when you edit an item in the Kanban board it edits the todo comment in the code?
- ribtoks 7y ago
  The ground truth is in the comments in the source file. Kanban board is a derived data. So I don't think it should work the other way round.
Endy 7y ago
It's amazing how much this applies to fiction writing, too. Having a clear outline and keeping it updated really helps - especially if you're not a linear writer and work on multiple points in a single session. Then again, if more amateur fiction writers did one thing well, I think that fiction in general would be improved.
- swozey 7y ago
  Do you have any suggested reads/videos for a budding writer? I get so overwhelmed with how to even start the process and plan it out and if I'm doing it correctly that I don't ever get to the important part; writing. I world build, draw out maps, plan characters then never write. Sometimes I wonder if I just enjoy world building. But I think I'm just intimidated.
  - Endy 7y ago
    I wish I did. I would suggest looking in Reddit's r/writing for advice.
nickjj 7y ago
This is partly why I really love the terminal Vim / tmux combo. Getting back into the swing of things is effortless. You can switch between projects within literally 2 seconds. It's so easy to resume exactly where you left off from the previous session. There's no need to tinker with window layouts or re-open code editors. Last month I made a video that goes over this workflow at (8:02 is the specifics on switching between projects): https://nickjanetakis.com/blog/using-tmux-sessions-windows-panes-and-vim-buffers-together https://nickjanetakis.com/blog/using-tmux-sessions-windows-p...
- ribtoks 7y ago
  There's nothing Vim specific as I use Vim and Qt Creator and even Emacs for different projects. All of them allow to open a "session" with one or more projects, but it's about what you were doing before in these projects, not the projects themselves.
  - nickjj 7y ago
    Sure, most editors have an idea of a session / project file that remembers layouts and open files of the individual project but terminal Vim (or any other terminal editor) is nice because it runs within a window of tmux directly. There's no external GUI program that gets spawned outside of tmux. Once that external program is launched, tmux can no longer control it. With GUI editors you'd have to use session / project files and then manually open / close your 1 instance of that editor when you switch between projects. It's kind of a clumsy experience (but doable).
    - maccard 7y ago
      I’m sorry but this is nonsense. I don’t doubt that your vim workflow works at all, and that’s great. There’s two major issues though - compared to entering my PC password, opening a tmux session vs clicking a button(or using a keyboard shortcut) is meaningless. Besides, for the last two decades, machines have had a sleep/hibernate functionality which means you can resume immediately, whether that’s a gui editor or a tmux session, with 0 interaction - I enter my password and my IDE is open, exactly where I left it (even in a debugging session if I needed it). > With GUI editors you'd have to use session / project files and then manually open / close your 1 instance of that editor when you switch between projects. It's kind of a clumsy experience I can’t think of a single gui editor that restricts you to one instance of it running, and I can’t think of a single gui editor which you would need to shut down to open a different session/workstation in. Visual studio for example has a list of recently opened projects in the file menu. In 3 clicks you can swap from one to another, or you can just open a second instance of it. Vs code has Ctrl r to “open recent” and you can choose from the command pallete (no mouse needed)
slashblake 7y ago
always leave a failing test
- jpitz 7y ago
  Sometimes I leave a note that flags as a compile error.
- ribtoks 7y ago
  Nice idea but it's only possible on quite small feature work. If you touch different bits and pieces of the codebase, you won't create a failing test for each edit. Plus, some things cannot be expressed in tests (e.g. "increase code coverage here") or will need additional metadata (e.g. issue, branch etc.) that will still require comments.
smallnamespace 7y ago
observe–orient–decide–act https://en.wikipedia.org/wiki/OODA_loop https://en.wikipedia.org/wiki/OODA_loop
- rzzzt 7y ago
  There is a very similar, five-letter (I think) mnemonic that you can invoke when making hard decisions, but I can't remember it for the life of me...
  - dragonwriter 7y ago
    The five-letter one I can think of is OPDCA, which is closely related to PDCA, which itself was (I believe) influenced by OODA. https://en.m.wikipedia.org/wiki/PDCA https://en.m.wikipedia.org/wiki/PDCA
  - deleted 7y ago
    [deleted]
- sixstringtheory 7y ago
  This reminded me a bit of the emergency response guide in Freedom of the Hills. Mountaineering instead of programming, but I can read it in terms of bug triage, refactoring, customer support... https://www.mountaineers.org/about/safety/safety-web-pages/during-an-emergency https://www.mountaineers.org/about/safety/safety-web-pages/d...
broth 7y ago
What typically works for me is just pencil and paper. I have a notebook that I use to log notes for each business day of the week. If I'm having trouble figuring out what I was working on during the previous day, I simply look at the previous day's notes. Writing notes helps commit things to memory better for me too. Also, using paper to write notes is less of a distraction than using an electronic medium to write notes in this day and age.
- forgotmypw3 7y ago
  This. It is so much easier than trying to remember everything.
rcarmo 7y ago
Very nice setup, but I just maintain a checklist in my READMEs using GitHub-flavored Markdown - works everywhere.
- ribtoks 7y ago
  Why not GitHub Issue using GitHub-flavored Markdown?
  - rcarmo 7y ago
    Because I don’t use GitHub for everything.
groovypuppy 7y ago
This is the hack I use: once I’m ready to stop for the day, I figure out a solution (usually to a small bug) but I stop myself from coding it. The next day, the code just flows from my fingers to the keyboard the second I sit down. Works like a charm and I’m right back into it. Just delaying the gratification of seeing another bug crushed.
- marcus_holmes 7y ago
  I do similar: make sure there's a failing test before I stop work for the day. Next day I just have to fix that test and I'm into it again.
- Pfhreak 7y ago
  This is my solution too, and it works great, but I find I have a hard time scaling it. Often, when a project reaches a certainly early/mid scale where I'm tackling some of the bigger problems, I'll push myself to work on it a little longer and finish it. If I might normally finish at 10pm, I'll push myself and go till 11:00 or midnight and finish the system. Then, because it's so late, I tend to just close everything out. And because I've just completed a milestone, I'm faced with not only getting back into flow, but beginning the process of designing/implementing a whole new big thing. It's at this point I really start to stumble, and I've lost a lot of projects to, "Whew, just finished that awesome system, I'm sure I'll pick this back up soon!" and I am at a total loss of how to power past these moments. If anyone has any ideas, I'm all ears.
  - eeeert 7y ago
    It's as if a primitive man saved enough berries at night to be able to eat some before foraging for more in the morning. You there's no concept of "scale" to something like this. Save a snack, a small task, for your brain to munch on in the morning, and you'll get in the routine much better than on an empty stomach.
    - banku_brougham 7y ago
      I wouldn’t say primitive, he might be very sophisticated. After all he’s the one that saved some berries and we are the ones fumbling around in the morning not knowing what to do.
kanaba 7y ago
>The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it. >I had learned already never to empty the well of my writing, but always to stop when there was still something there in the deep part of the well, and let it refill at night from the springs that fed it. -Ernest Hemingway https://dianedrake.com/wp-content/uploads/2012/06/Hemingway-Monologue-to-the-Maestro1.pdf https://dianedrake.com/wp-content/uploads/2012/06/Hemingway-...
tastyfreeze 7y ago
I carry around a notebook to write down ideas or solutions that have been grinding away since the last time I sat down to code. On the computer I keep a running task list using notepad for session notes and gitlab kanban for larger tasks. I find that most of the time my session notes are enough to pick up where I left off. If I'm between tasks time to grab a new one from kanban. If an idea pops up while I'm working on something else it is vital to enter a TODO in the source and an issue in gitlab and get back to what I was working on. Gotta stay on task without going down a rabbit hole.
- ribtoks 7y ago
  I've been doing exactly the same but with OneNote instead of notepad and GitHub kanban instead of GitLab kanban. At some point I just decided to get some automation done..
aj7 7y ago
I budget some time, say 10 minutes before I have to end to summarize the next steps and also to summarize the state of hard problems I’m having.
SingAlong 7y ago
I use git commit messages for this. When I stop working, my commit messages look like these. “Completed ABC; TODO XYZ” “WIP ABC; TODO XYZ” When I get back, all I have to do is check the previous commit.
makach 7y ago
Although the flow is a great place to be in, and I enjoy it very much every time I incidentally discover I am in it. It is not something I actively try to achieve. I believe it can be counter-productive. It must not be a requisite for being able to work.
DecoPerson 7y ago
I used to record my desktop all the time, and then even after a short interruption review it to mentally retrace my thought flow. Now I just use IntelliJ's Ctrl+Alt+Left/Right shortcuts to jump around the places I was looking at / modifying. Though reviewing footage was more effective; I might start doing that again. (For context, I am a game designer at AAA studio and I write a lot of code.)
- pibefision 7y ago
  How do you record it? QuickTime or an external hdmi recorder? Seems a good tip!
Speakeasys 7y ago
I like how the author put a shameless plug right in the middle of the article for something he wrote. Lol
- ribtoks 7y ago
  There's no plug, all screenshots are from my attempts to manage my work better on one of my hobby projects. This is where it all started.
agumonkey 7y ago
What about embracing breaks. If you lose it, bookmark things a bit. Go doing something mindless for 20 minutes (walking), when possible something productive .. and when the energy comes back, jump right where you left and dive.

330 points by ribtoks 7y ago

In a nutshell: Know your goal, know what just happened, know what to do next. Maybe obvious, but I agree, critical, and a good thing to make explicit to oneself. The author presents a lot of seemingly complex tools for this. Mine are, I believe, simpler -- a TODO list in .org mode (goal and next), and git log (for what just happened, always with --name-status to show what files were affected how, and maybe with -p to show the diff). But you could use anything.

ribtoks 7y ago
Sure, but whenever you feel like you have an idea, you have to open your TODO list in org mode and update it. Also when you finish your intermediate goal, you have to again go to your file and mark item as done. In my case when you remove the comment right in the file you're working on, the task gets closed. Simple automation.
- bcrosby95 7y ago
  It doesn't need to be a specific TODO file. I have a dev log in org mode. Any thoughts about what I'm working on go there. Including TODOs. It's always open, so there is no open/save/close process. Of course, I have to update it. But it's just one more file that gets updated. It's not onerous. Plus, I'm not destroying documentation about my development process. I have used this method since I started developing professionally 15 years ago. I can go back over a decade and look into why I did certain things for a piece of code and how I decided to break the work apart.
  - na85 7y ago
    Wow, how big is your dev log file?
- WhatIsDukkha 7y ago
  It's pretty trivial to keep an open "project.org" buffer open for whatever project I'm working on. This is pretty natural in emacs but sometimes vim users aren't as confident with tabs or buffers. There is also https://github.com/alphapapa/outshine https://github.com/alphapapa/outshine Which gives you "full" orgmode in comment sections of your normal source code (haven't actually tried it myself). Overall I think you are on the right track with your goals but, yes, orgmode does a great job of solving them already with a bunch of additional features too.
  - ribtoks 7y ago
    First of all, the buffer will be too small for all tasks created on a branch and you don't want to have this buffer big, unless you have 2 monitors and have Emacs frame with this buffer opened for a half of it. Also this process is not automatic - you have to navigate to the buffer and close the task when it's done. Also from the that buffer it's impossible to sync outside (GitLab/GitHub) or share your tasks with a team, what is possible with Kanboard if it's running on DigitalOcean/Heroku or simply synchronizes with GitHub.
    - merlincorey 7y ago
      If one really wanted to do it all in emacs' org-mode but also have it be automated and sycned with the code, I believe the solution would resemble something along the following lines: Literate Programming in the Knuth sense with org-mode file using tangle[0] blocks holding the source code which can be used to generate and build the project, and a combination of regular emacs lisp code and some org-mode evaluated emacs lisp[1] to do whatever automation is needed. Now the TODOs can be in the org file, which contains the source, and may also have a reference (automated) to the TODO, which when closed with the regular org-mode command (and is generally only two key chords) will remove the comment as well as update your agenda, calendar, kanban, etc. [0] https://orgmode.org/manual/tangle.html https://orgmode.org/manual/tangle.html [1] https://orgmode.org/manual/Evaluating-code-blocks.html https://orgmode.org/manual/Evaluating-code-blocks.html
- Jeff_Brown 7y ago
  If all my open problems could be localized in a single place in the codebase, I might indeed keep all my todo items as comments. But sometimes they span a lot of the code. The organizing principle of the todo document is problems. The organizing principle of the code is something else -- control, data. Perhaps ideally they would align, but in my experience they don't.
  - ribtoks 7y ago
    The point of todo comments is that they are written across all your codebase and the system collects them and visualizes without manual intervention.
    - Jeff_Brown 7y ago
      Oh. That does sound pretty nice.
dfsegoat 7y ago
Apologies for the ineptitude: What is .org mode for a TODO list?
- dmamills 7y ago
  https://orgmode.org/ https://orgmode.org/ should help :)
wpietri 7y ago
One addition I'd make to this is unit tests. I try to stop with a failing unit test, which gives me a really obvious place to start when I pick it up again the next work session.

merlincorey 7y ago

The author found they needed a terminal replacement to `gitk` and they chose `lazygit`, but I would also like to recommend `tig`[0] as a commandline git browser. The mentioned kanban software, `kanboard`[1], is super easy to setup and use -- I did a survey of about 10 self-hosted kanban software tools and this was definitely a front-runner in terms of overall simplicity and ease of setup and use. I did not review the plugin architecture at the time, but glad to hear that it is fairly straightforward. [0] https://jonas.github.io/tig/ https://jonas.github.io/tig/ [1] https://kanboard.org/ https://kanboard.org/

cookingrobot 7y ago

Interesting approach. What would you think of having it sync the other way as well - when you edit an item in the Kanban board it edits the todo comment in the code?

ribtoks 7y ago
The ground truth is in the comments in the source file. Kanban board is a derived data. So I don't think it should work the other way round.

Endy 7y ago

It's amazing how much this applies to fiction writing, too. Having a clear outline and keeping it updated really helps - especially if you're not a linear writer and work on multiple points in a single session. Then again, if more amateur fiction writers did one thing well, I think that fiction in general would be improved.

swozey 7y ago
Do you have any suggested reads/videos for a budding writer? I get so overwhelmed with how to even start the process and plan it out and if I'm doing it correctly that I don't ever get to the important part; writing. I world build, draw out maps, plan characters then never write. Sometimes I wonder if I just enjoy world building. But I think I'm just intimidated.
- Endy 7y ago
  I wish I did. I would suggest looking in Reddit's r/writing for advice.

nickjj 7y ago

This is partly why I really love the terminal Vim / tmux combo. Getting back into the swing of things is effortless. You can switch between projects within literally 2 seconds. It's so easy to resume exactly where you left off from the previous session. There's no need to tinker with window layouts or re-open code editors. Last month I made a video that goes over this workflow at (8:02 is the specifics on switching between projects): https://nickjanetakis.com/blog/using-tmux-sessions-windows-panes-and-vim-buffers-together https://nickjanetakis.com/blog/using-tmux-sessions-windows-p...

ribtoks 7y ago
There's nothing Vim specific as I use Vim and Qt Creator and even Emacs for different projects. All of them allow to open a "session" with one or more projects, but it's about what you were doing before in these projects, not the projects themselves.
- nickjj 7y ago
  Sure, most editors have an idea of a session / project file that remembers layouts and open files of the individual project but terminal Vim (or any other terminal editor) is nice because it runs within a window of tmux directly. There's no external GUI program that gets spawned outside of tmux. Once that external program is launched, tmux can no longer control it. With GUI editors you'd have to use session / project files and then manually open / close your 1 instance of that editor when you switch between projects. It's kind of a clumsy experience (but doable).
  - maccard 7y ago
    I’m sorry but this is nonsense. I don’t doubt that your vim workflow works at all, and that’s great. There’s two major issues though - compared to entering my PC password, opening a tmux session vs clicking a button(or using a keyboard shortcut) is meaningless. Besides, for the last two decades, machines have had a sleep/hibernate functionality which means you can resume immediately, whether that’s a gui editor or a tmux session, with 0 interaction - I enter my password and my IDE is open, exactly where I left it (even in a debugging session if I needed it). > With GUI editors you'd have to use session / project files and then manually open / close your 1 instance of that editor when you switch between projects. It's kind of a clumsy experience I can’t think of a single gui editor that restricts you to one instance of it running, and I can’t think of a single gui editor which you would need to shut down to open a different session/workstation in. Visual studio for example has a list of recently opened projects in the file menu. In 3 clicks you can swap from one to another, or you can just open a second instance of it. Vs code has Ctrl r to “open recent” and you can choose from the command pallete (no mouse needed)

slashblake 7y ago

always leave a failing test

jpitz 7y ago
Sometimes I leave a note that flags as a compile error.
ribtoks 7y ago
Nice idea but it's only possible on quite small feature work. If you touch different bits and pieces of the codebase, you won't create a failing test for each edit. Plus, some things cannot be expressed in tests (e.g. "increase code coverage here") or will need additional metadata (e.g. issue, branch etc.) that will still require comments.

smallnamespace 7y ago

observe–orient–decide–act https://en.wikipedia.org/wiki/OODA_loop https://en.wikipedia.org/wiki/OODA_loop

rzzzt 7y ago
There is a very similar, five-letter (I think) mnemonic that you can invoke when making hard decisions, but I can't remember it for the life of me...
- dragonwriter 7y ago
  The five-letter one I can think of is OPDCA, which is closely related to PDCA, which itself was (I believe) influenced by OODA. https://en.m.wikipedia.org/wiki/PDCA https://en.m.wikipedia.org/wiki/PDCA
- deleted 7y ago
  [deleted]
sixstringtheory 7y ago
This reminded me a bit of the emergency response guide in Freedom of the Hills. Mountaineering instead of programming, but I can read it in terms of bug triage, refactoring, customer support... https://www.mountaineers.org/about/safety/safety-web-pages/during-an-emergency https://www.mountaineers.org/about/safety/safety-web-pages/d...

broth 7y ago

What typically works for me is just pencil and paper. I have a notebook that I use to log notes for each business day of the week. If I'm having trouble figuring out what I was working on during the previous day, I simply look at the previous day's notes. Writing notes helps commit things to memory better for me too. Also, using paper to write notes is less of a distraction than using an electronic medium to write notes in this day and age.

forgotmypw3 7y ago
This. It is so much easier than trying to remember everything.

rcarmo 7y ago

Very nice setup, but I just maintain a checklist in my READMEs using GitHub-flavored Markdown - works everywhere.

ribtoks 7y ago
Why not GitHub Issue using GitHub-flavored Markdown?
- rcarmo 7y ago
  Because I don’t use GitHub for everything.

groovypuppy 7y ago

This is the hack I use: once I’m ready to stop for the day, I figure out a solution (usually to a small bug) but I stop myself from coding it. The next day, the code just flows from my fingers to the keyboard the second I sit down. Works like a charm and I’m right back into it. Just delaying the gratification of seeing another bug crushed.

marcus_holmes 7y ago
I do similar: make sure there's a failing test before I stop work for the day. Next day I just have to fix that test and I'm into it again.
Pfhreak 7y ago
This is my solution too, and it works great, but I find I have a hard time scaling it. Often, when a project reaches a certainly early/mid scale where I'm tackling some of the bigger problems, I'll push myself to work on it a little longer and finish it. If I might normally finish at 10pm, I'll push myself and go till 11:00 or midnight and finish the system. Then, because it's so late, I tend to just close everything out. And because I've just completed a milestone, I'm faced with not only getting back into flow, but beginning the process of designing/implementing a whole new big thing. It's at this point I really start to stumble, and I've lost a lot of projects to, "Whew, just finished that awesome system, I'm sure I'll pick this back up soon!" and I am at a total loss of how to power past these moments. If anyone has any ideas, I'm all ears.
- eeeert 7y ago
  It's as if a primitive man saved enough berries at night to be able to eat some before foraging for more in the morning. You there's no concept of "scale" to something like this. Save a snack, a small task, for your brain to munch on in the morning, and you'll get in the routine much better than on an empty stomach.
  - banku_brougham 7y ago
    I wouldn’t say primitive, he might be very sophisticated. After all he’s the one that saved some berries and we are the ones fumbling around in the morning not knowing what to do.

kanaba 7y ago

>The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it. >I had learned already never to empty the well of my writing, but always to stop when there was still something there in the deep part of the well, and let it refill at night from the springs that fed it. -Ernest Hemingway https://dianedrake.com/wp-content/uploads/2012/06/Hemingway-Monologue-to-the-Maestro1.pdf https://dianedrake.com/wp-content/uploads/2012/06/Hemingway-...

tastyfreeze 7y ago

I carry around a notebook to write down ideas or solutions that have been grinding away since the last time I sat down to code. On the computer I keep a running task list using notepad for session notes and gitlab kanban for larger tasks. I find that most of the time my session notes are enough to pick up where I left off. If I'm between tasks time to grab a new one from kanban. If an idea pops up while I'm working on something else it is vital to enter a TODO in the source and an issue in gitlab and get back to what I was working on. Gotta stay on task without going down a rabbit hole.

ribtoks 7y ago
I've been doing exactly the same but with OneNote instead of notepad and GitHub kanban instead of GitLab kanban. At some point I just decided to get some automation done..

aj7 7y ago

I budget some time, say 10 minutes before I have to end to summarize the next steps and also to summarize the state of hard problems I’m having.

SingAlong 7y ago

I use git commit messages for this. When I stop working, my commit messages look like these. “Completed ABC; TODO XYZ” “WIP ABC; TODO XYZ” When I get back, all I have to do is check the previous commit.

makach 7y ago

Although the flow is a great place to be in, and I enjoy it very much every time I incidentally discover I am in it. It is not something I actively try to achieve. I believe it can be counter-productive. It must not be a requisite for being able to work.

DecoPerson 7y ago

I used to record my desktop all the time, and then even after a short interruption review it to mentally retrace my thought flow. Now I just use IntelliJ's Ctrl+Alt+Left/Right shortcuts to jump around the places I was looking at / modifying. Though reviewing footage was more effective; I might start doing that again. (For context, I am a game designer at AAA studio and I write a lot of code.)

pibefision 7y ago
How do you record it? QuickTime or an external hdmi recorder? Seems a good tip!

Speakeasys 7y ago

I like how the author put a shameless plug right in the middle of the article for something he wrote. Lol

ribtoks 7y ago
There's no plug, all screenshots are from my attempts to manage my work better on one of my hobby projects. This is where it all started.

agumonkey 7y ago

What about embracing breaks. If you lose it, bookmark things a bit. Go doing something mindless for 20 minutes (walking), when possible something productive .. and when the energy comes back, jump right where you left and dive.