Hacker News Reader

Comment by alf | Hacker News Reader

The Hemingway Trick: Stop in the middle. Never stop working at the natural barriers. They next time you start working, the barrier will be the first thing you encounter, and you won't have the momentum to overcome it. Try to stop writing mid-chapter, or mid-sentence (or mid function). Know how to finish, but stop working. The next time you start, you know exactly what needs to be done. There will even be the urge to start working to finish the unfinished.

Nearing the end of a unproductive day, accept that the day was not productive, start on what you will work on tomorrow, do a little, and stop in the middle.

View on HN

Kent Beck calls this the "Red Test Pattern". If you do test-driven development, check in your code, write one more test that fails, and only then stop working.

Works wonders for me.

Agree - this pattern is really underestimated.

I find it especially powerful at the end of a long day when you've been deep in the details. When you come in the next morning and see that red test, you "download" the context you were in much more quickly. I've also noticed that you tend to remember little details and nuances more clearly.

This is a very interesting statement that I've read before.

It is interesting because it deals with the moment you're working and not about the moment you're procrastinating. Because yeah we've all read those articles while procrastinating which gave miracle solution. Never works.

This is a real solution.

It doesn't tell you what to do to stop procrastinating, it tells you how to stop working as not to procrastinate the next day.

It is a lifestyle about knowing WHEN to stop something. And I truly believe it can be applied in a lot of life situations.

When you talk to a girl, don't wait the last minute, when the conversation starts getting boring, to leave. Leave in the middle of a conversation, leave when it's interesting. She will keep a good memory of you in mind and the next time you meet her you guys will be at a peak of exchange.

I think I first read it here on HN actually :)

I think this trick is so great because it's so counter intuitive to a person in the mindset of getting something done. Stopping when you still have momentum seems counter productive, and it is in the short term, but you get more done in the long run.

Finding a way to start work without immediately hitting barriers was so important while writing my bachelor thesis. I now sort of whish I had known about your tip earlier, that seems easier than having to actively search for a simple way to start while procrastinating.

That said, sometimes it seems it was necessary for me to stop work and just do nothing for a while in order to find that important insight.

See Psychology of Invention in the Mathematical Field Jacques Hadamard, published around 1900. Once you have immersed yourself in a problem, going about normal daily tasks not related to the problem allows your mind to churn and make connections. Sudden (Gestalt like) insight may occur.

Thanks for sharing this insight. It really struck me with its simplicity. It happens all the time. When I have a clear notion of how to continue, I can't wait to start coding the next day. Just the opposite happens when I am left with a "blank page", and I have to force myself to start working.

Similar to the idea of stopping in the middle: leave something easy. Leave a small task, an easy one, un-done so that you can start with it next time. It works for the same reason, you don't immediately encounter a barrier when you start back up.

Agreed, this works like a charm. Interesting that this topic comes up today since the Wall Street Journal addressed the Hemingway trick (among other great tips) just yesterday: "How to Save an Unproductive Day" http://online.wsj.com/article/SB1000142405297020477040457708...

Great advice, Alf.

I find this quite interesting because it deviates from what I thought Hemingway's Trick would have been: be a ruthless bastard.

The real Hemingway Trick definitely has its benefits because it lets your algorithm/design/idea develop in your head over time. Brute force coding, even if it works, can lead to sloppy and less efficient code. This leads to an important question: at what point does one trade "beast mode" for rest?

I read an article on HN about how the difference between great and mediocre musicians is the amount of time spent on focused practicing. Total hours mean nothing, only the amount of time spent on meaningful practice matters.

With this being said, it's important to develop a plan of action, and then stay incredibly focused on that for a few short hours. Once that roadblock is hit hit, take a break, let your brain do some processing, and then go back to a focused hack a little later and walk away with substantial progress.

Key is: know how to finish. Otherwise you (I) will spend the night awake thinking about how to finish.

This works extremely well for me. I wouldn't recommend stopping mid-sentence but leaving an implementation incomplete (eg. just have to fill out another method and everything fits together) allows me to start the next day running.

The problem is that I can't stop like that. If I try to stop in the middle the problem just haunts me until I come back and finish it.

I believe that is the point.

Not when you can't think about much else until you come back to it. I'm trying to get out of the habit of thinking about work 24/7. Leaving unfinished problems does not help my goal.

Any project is a series of unfinished problems.

If you have something on your mind, write it down - but don't actually finish the work.

I love this idea. Do you have a source where Hemingway describes it? I wonder if others have suggested this under other names (I see the Red Test Pattern below.)

I know when life forces me to do this, it works very well. The trick is doing it on purpose.

Actually actionable useful advice for people like us. I like it. Going to try it.

Reply on news.ycombinator.com