[tptacek]

A variant (I think) of this idea that I've been using for years: when I stop coding, I jot down what I was doing, whatever problems I was dealing with, and what I felt my next steps were going to be in a little Emacs buffer.

It would probably be even smarter of me to take 20 seconds to figure out exactly the right set of Emacs tabs/frames to keep open alongside them, so when it was time to start up again, I'd get sucked right in.

[CamperBob2]

A related trick I find valuable is to do the exact opposite of what the article suggests. Never finish anything at the end of your workday. Leave yourself a small mess to clean up, or some simple and finite wrapup task that you can afford to postpone. Bonus points if it's going to be fun or interesting to work on.

The idea being, it'll be much easier to get back into the groove the next day if you aren't confronted with the proverbial empty screen or blank sheet of paper the minute you walk in the door.

After you spend 30 minutes wrapping up the work from yesterday, you will already be in the zone, and it'll be easier to move ahead to the next big thing on your list.

[Gorgias]

This is a trick Hemingway used when writing.

"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 … you will never be stuck. Always stop while you are going good and don’t think about it or worry about it until you start to write the next day. That way your subconscious will work on it all the time. But if you think about it consciously or worry about it you will kill it and your brain will be tired before you start."

I often create fun little mini-projects for myself to do and store them for later. I find that completing a small and fun project motivates me to work on whatever actual task I should be working on.

[scott_s]

I do this, and I find it's invaluable. If it's the end of the day, and I have a writing or coding task to do that is small in scope and I'm looking forward to doing, I put it off to the next day.

I think of it as leaving work "hooks" for myself to pull me into work the next day. Work hooks are small in scope, and satisfying to accomplish. The next day, not only do I know exactly what I'm going to do, I'm looking forward to it.

[nnq]

YUCK! ...this is one of those things that works great for a group of people bu completely sucks for another group: for me having "a blank piece of paper" in front of me is the most motivating thing ever (I always have a zillion things in my head or on my lists that I want to work on, so the only problem is ordering them and trying to do as much as I can with my limited time, physical energy and for some tasks money). Sometimes I even literally take a blank piece of paper and stare at it while meditating because it's exactly what puts me in the mood to start working on things. and I literally LOVE an almost empty desk or a completely empty desktop with no programs open.

...but I know there are the opposite kind o people, like fellow programmers that love debugging but are just "stuck" if they have to start from scratch (I'm the opposite, I hate debugging and working on projects started by other people, but I'm incredibly productive at starting from a blank whiteboard or imagining things from nothing)

[wpietri]

Yes. My coding trick for this is to clean everything up, except that I write the next test that I want to pass. Then when I come in the next day, everything is shipshape (which, as the article explains, makes it easy to start). Except that one red test, which drags me right into the red-green-refactor loop.

[naglfar]

Even though I have not used it myself (yet - I should probably try it as well) - shouldn't the Emacs desktop mode just store all open tabs and restore them for you when activated: http://www.gnu.org/software/emacs/manual/html_node/emacs/Sav...

[skrebbel]

This is related to what Kent Beck calls the "Red Test Pattern". When doing Test-Driven Development, don't stop when the last test is green and refactored; commit/push your code, and then write that next test, the one for the next functionality you want to realise. Check that it fails. Then shut down.

Next day, you'll be sucked right back in because of that damn test failing.

For me, it's also a good way to keep habitually doing TDD.

[JoeAltmaier]

I use old-fashioned paper and pen. Keep a todo list on a page; each day-end I add/subtract and when it gets full, copy it to a new page. This makes me revisit each item, which may create associations to newer tasks that are related.

When I start from neutral, whether at start-of-day or after finishing a task, I check off what's done, then review the list to find a ripe task to launch into.