Fire And Motion (2002)

I've definitely found that if I can trick myself into getting started, I often end up looking back on a productive day.

The Pomodoro approach has been somewhat successful in making this happen. Another approach that works well for me is the 'Final Version' productivity 'system' by Mark Forster [1]. The key trick is that it's okay to just do 'a bit' of something on your list and then mark it as completed (and re-add it to the end of the list).

In the past I've been a heavy GTD user. I abandoned GTD mostly because I feel it doesn't really fit my kind of work, but I still apply two GTD principles because they're also primarily about lowering the barrier to getting started: 1) turn big tasks into small steps that are easier to get started with, and 2) the 'two minute rule' where if you can do something in two minutes time or less, just do it immediately and don't bother adding it to your system.

I've come to the conclusion that for me, the 'getting started' part is so important to optimize for that everything else feels like little more productivity porn, at least until I get that part somewhat working.

[1]: http://markforster.squarespace.com/blog/2015/5/21/the-final-...

Here's a getting started hack from Ernest Hemingway, since programming can be like writing in that work is more independent for much of it:

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.

Leave something almost complete, at a compile fix state or with less cognitive loading steps to start up the next day with the ball rolling.

I find it so valuable when people in this kind of position within the software industry admit their human faults.

It is so easy to fall into the trap of impostor syndrome. We all have these problems, and coupled with the potential complexity of some programming tasks it can feel overwhelming.

> There’s something incredible heavy in my brain that is extremely hard to get up to speed, but once it’s rolling at full speed, it takes no effort to keep it going.

I noticed that too. I could be wrong, but I believe the painful part is loading everything you need into short-term memory.

> The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP.

It's interesting to read this essay again in the context of 2017 Javascript Fatigue, and especially the seemingly endless froth in the React ecosystem.