Hacker News new | ask | show | jobs
by codelobe 854 days ago
To lessen the cost of the first step that begins The Thousand Mile Journey: I plan to do everything at least twice. Leave room for failure in the prediction to (at least partially) avoid the planning fallacy.

https://en.wikipedia.org/wiki/Planning_fallacy (if you haven't encountered this one weird quirk yet, it's a must read/skim). I believe most mammals tend toward optimism... They naturally have less fear of doomed endeavors.

I had an essay on Emergent Design Principles around here somewhere... For instance, I do a quick and dirty stab in the dark to map the problem space. Then totally rewrite and refactor now that I can make a more educated guess. Right then I generate the API and all (public function stubs), organizing and documenting everything. Management will demand I "ship it" without full docs and full of kluges otherwise...

I'll save the rest of that for a more on-topic thread. The gist is that procrastination can be countered by allotting time to play around in the problem space (incorporate procrastination into workflow -- can't beat it, join it). At worse I try a deliberate attempt at failure (well I knew it wouldn't have worked, but it would have been cool if it had), and at least I got myself into "code mode" doing something at all. No fear of failure, since I planned to fail that time anyway. Then I'll at least know a bit better the "lay of the land" (problem space features to fit against). It's oft the first step for me that's the hardest.

My favorite trick is to have at least one side project that I work on as procrastination of doing main projects. Without fail I'll be worrying about the main project enough that I'll realize some side-project procrastination-code I've just written shows an elegant way forward in the main project and I can no longer resist the urge to see it in action. At the least I'll be making some manner of progress, and getting closer to that "Zen" state wherein I do my main project work.