
Boost your productivity with Hemingway’s hack - berlinbrown
http://www.secondactive.com/2009/08/boost-your-productivity-with-hemingways.html
======
BigZaphod
I've seen this kind of advice related to writing before. The idea is you may
be working on a scene and it's almost all written/described/finished. You stop
before the end and move on to something else. When you come back to the scene,
you'll be able to merge it into the rest of the story more easily now -
perhaps even because you've realized what needed to happen after the scene
(because you moved on to start that part before you had finished the first
part). This is supposed to avoid the block of wondering, "so now what needs to
happen next?" where your brain starts getting stuck in a loop of endless
possibility because the search space has become unbounded.

I do think this is one of those "easier said than done" kind of things,
similar to "buy low, sell high." However I've had days where I've done the
equivalent while coding. Say, while working on an increasingly large method
and then stopping because I need some additional, independent functionality.
So I put the big method aside and build that functionality only to come back
and notice that I can now factor out some prior stuff in this big method and
call parts of the other method I was working on.. and oh if I do that again,
look - more things in common! And factoring just kind of happens all before I
even knew exactly what the big method originally was going to do in the first
place. (In some cases, the big method just disappears entirely and there's
nothing left of it.) Of course if I could make this happen all the time on
demand, I'd be golden...

------
alanthonyc
Sounds familiar...this is what I do when I procrastinate.

------
protothomas
There's always the danger, though, that you will run into Zeno's paradox.

~~~
derefr
Don't aim for 100%. Aim for 120%, then throw the worst 6th away. Basically the
same as the advice for runners: aim _past_ the finish line.

------
dws
This advise carries over to software development. To give yourself focus the
next morning, leave yourself with a breaking test.

~~~
silentbicycle
Or, more generally, know what you're going to work on next, and have enough
context to hit the ground running. If you get to the office / update your repo
/ etc. and have to spend half an hour figuring out what to work on next,
you're not going to carry any momentum over.

------
JshWright
I find a more effective version of this trick is to leave some "gimme" task
for the next day. I always try to make sure I leave some easy, 15-minute task
for the next day. That doesn't mean I don't complete what I'm currently
working on however...

------
dpifke
I don't know about always stopping when I'm going good, but I almost always
leave myself with a concrete "next step" for the next day when I do decide to
stop. Sometimes this means getting the task I'm working on to 95% completion,
or forcing myself to work a bit longer so that one of tomorrow's tasks is
already started and approximately roughed out (tests written or methods
stubbed or HTML roughly laid out).

If the day's boundary falls on a major task boundary, the next day starts with
me figuring out what to work on next - not nearly as conducive to "getting
into the groove" as tying up a few loose ends and _then_ jumping on whatever I
need to work on next.

------
diN0bot
do you ever start planning what you're going to code next while you're falling
asleep, or when you take a toilet break or walk somewhere? or when you go to a
meeting and sketch out that new module or whatever?

reminds me of a hemingway hack. it's hard to sit down to my computer with no
specific goal in mind, or just the high level "i have to finish this story" in
mind. it's easy to slide into other things.

but if i've been visualizing the code i want to write, or if i have a sketch
of the data or algorithm, then i don't waste time.

------
ojbyrne
I fail to see how this helps to "avoid being stuck," in fact it seems more
likely to result in you sitting looking blankly at half a page somewhere in
the middle of the day.

------
Tichy
So when do you work? I suppose when you don't know what to do?

~~~
christofd
A rough assessment - needs some more thought:

Exactly. This advice might apply more to a creative process, where original
thought counts above all else. I imagine being truly creative is an exhausting
activity, knowing several professional artists (oil paint). You're basically
holding a large set of options simultaneously in your head and try to make
unique connections between them. The value is not in how many iterations of
connections you go through, but coming up with something unique at all.

Development strikes me more similar to solving cross-word puzzles, or playing
mine-sweeper, where activity is more guided, focused along a smaller set of
options, with lots of trial and error in the process: it's sort of "focused
play"/ experimentation. Here it seems more valuable IMHO to keep on going once
you're in the flow. You're not looking for that one special connection, that
will make your day, but are solving many little problems that aggregate over
time.

I could imagine science-based development work to be creatively exhausting as
well, where you're trying to prove some theorem etc. Hemingway's advice might
apply itself nicely in this case.

I'd like to see more blog posts on how to solve different types of problems.
E.g. I know that walking away from a hard problem after you're exhausted works
out well (the subconscious keeps on working on it), or as Hemingway proposes,
walking away right before you become exhausted.

My two cents.

------
pvg
Not sure 'Hemingway hacks' is really a great model to follow given that they
include 'shooting yourself in the face. with a shotgun'.

~~~
jrockway
His writing is good.

------
tfh
Reading _"Hemingway's hack"_ , I thought it has something to do with alcohol.

~~~
pstuart
Reading your comment, I thought it has something to do with cigarettes.

