Hacker News Reader

Comment by groovypuppy | Hacker News Reader

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.

View on HN

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.

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

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

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.

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

Reply on news.ycombinator.com