How to return to the flow faster

https://codejamming.org/2019/how-to-return-to-flow

by ribtoks • 7 years ago

330 58 7 years ago

Jeff_Brown3• 7 years 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.

ribtoks9• 7 years 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• 7 years 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.

WhatIsDukkha• 7 years 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

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.

Jeff_Brown3• 7 years 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.

dfsegoat• 7 years ago

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

dmamills• 7 years ago

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

wpietri• 7 years 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.

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

cookingrobot• 7 years 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?

ribtoks9• 7 years 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.

Endy2• 7 years 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• 7 years 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.

Endy2• 7 years ago

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

nickjj3• 7 years 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-p...

ribtoks9• 7 years 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.

nickjj3• 7 years 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).

slashblake• 7 years ago

always leave a failing test

jpitz• 7 years ago

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

ribtoks9• 7 years 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• 7 years ago

observe–orient–decide–act

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

rzzzt• 7 years 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• 7 years 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

sixstringtheory• 7 years 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/d...

broth• 7 years 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• 7 years ago

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

rcarmo2• 7 years ago

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

ribtoks9• 7 years ago

Why not GitHub Issue using GitHub-flavored Markdown?

rcarmo2• 7 years ago

Because I don’t use GitHub for everything.

groovypuppy• 7 years 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.

Pfhreak• 7 years 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• 7 years 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.

zrobotics• 7 years ago

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.

fitzroy• 7 years ago

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

marcus_holmes• 7 years 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.

Ocerge• 7 years ago

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.

sh87• 7 years ago

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.

dybber• 7 years ago

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

kanaba• 7 years 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-...

tastyfreeze• 7 years 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.

ribtoks9• 7 years 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• 7 years 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• 7 years 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• 7 years 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• 7 years 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• 7 years ago

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

Speakeasys• 7 years ago

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

ribtoks9• 7 years 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• 7 years 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.

How to return to the flow faster

Related Stories