How to return to the flow faster | Hacker News Reader

How to return to the flow faster

codejamming.org

330 pointsribtoks58 comments

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.

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.

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.

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.

Keep a list of small features/tweaks to the side and use them as jumping off points. Takes a little bit of forethought, but I keep a txt file in the repo with a list of things like class implementation tweaks or ui changes that I know are 15-30 minute tasks. I reserve these for when I'm having trouble ramping up.

Or failing that, 15 minutes of cranking out garbage code that I know I'll revert helps get back into flow state too, but it's demoralizing deleting work.

It might feel demoralizing but writing and testing out throwaway code is part of figuring things out. Writing that code helped you get to a point where you have better insight.

This is similar to the idea of writers who stop writing mid-sentence so that it becomes a springboard to continue the next day.

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.

This is what I try to do as well, and it works so well; it's very motivating to know that you have a comfortable starting place to come to in the morning. Another thing I've started to do whenever I don't necessarily have a bug is to just run our entire suite of unit tests. We are usually pretty good about keeping everything green across the board so it almost never results in anything worth fixing, but just typing _something_ is more often than not enough to get me into working on the next story or whatever.

This did not work for me.

What did however was an analysis of 1) what I did yesterday and 2) what I want to today. I started with just typing my head off for about 30 mins every morning. At first it was thoughts all over the place. As I kept at it and pushed through, over a few weeks on I could see patterns emerge. I could read what going on yesterday, a week ago or a couple of sprints ago or a release ago and see how things have evolved. This helped separating the important stuff from the fluff. This was what I needed to focus on. I now log the important stuff. Takes about 10 minutes a day and gets me in the flow of things. Totally worth the effort in time and mental cycles spent.

The trick is called Hemingway’s Hack: http://www.ajkesslerblog.com/hemingways-productivity-hack/

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.

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.

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.

Wow, how big is your dev log file?

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

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.

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.

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

[1] https://orgmode.org/manual/Evaluating-code-blocks.html

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.

The point of todo comments is that they are written across all your codebase and the system collects them and visualizes without manual intervention.

Oh. That does sound pretty nice.

Apologies for the ineptitude: What is .org mode for a TODO list?

https://orgmode.org/ should help :)

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.

>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-...

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/ [1] https://kanboard.org/

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.

This. It is so much easier than trying to remember everything.

observe–orient–decide–act

https://en.wikipedia.org/wiki/OODA_loop

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...

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

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/d...

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-p...

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.

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).

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)

> Besides, for the last two decades, machines have had a sleep/hibernate functionality which means you can resume immediately

Hibernate isn't dependable, especially not on a Windows box where it will do a full reboot to update itself which is out of your control. Also hibernate is quite buggy (even after 2 decades) and doesn't assist in switching between projects.

> I can’t think of a single gui editor that restricts you to one instance of it running...

You can run more than 1 copy of a GUI editor for sure, but are you really going to open 8 independent copies of VSCode? How will you pick which one to use? Would you put each one in its own independently labeled virtual desktop or put them all into 1 virtual desktop and now juggle 8 VSCode icons in your taskbar? That seems like a massive burden from a usability POV and from a system resource POV one copy of VSCode with a "full time developer" amount of plugins uses around 600mb of memory just to open it once. So if you had 8 of those open you would use around ~5 gigs of memory, and chances are your idle CPU is going to be jacked up too even when not typing into any of them (it does for me on my Windows box).

With terminal Vim you don't need to worry about system resources ever. It uses less than 10mb of memory even with 40+ plugins and your CPU load stays at zero even if you have 17 copies of Vim running (which is what I have currently running).

Open recent is also not dependable because chances are you're opening and editing things that aren't projects all the time (such as config files, etc.). This isn't all theory either. I used VSCode for over a year and these are all real problems I ran into. I only recently switched to Vim (relatively speaking) and all of those project management problems I had went away.

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.)

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

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.

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.

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.

I wish I did. I would suggest looking in Reddit's r/writing for advice.

always leave a failing test

Sometimes I leave a note that flags as a compile error.

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.

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.

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..

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.

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

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.

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?

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.

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.

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

Why not GitHub Issue using GitHub-flavored Markdown?

Because I don’t use GitHub for everything.

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.

Reply on news.ycombinator.com