Overcoming Project Paralysis

I’m fighting passion project paralysis.

I want to work on an open source project, but I can’t seem to find the energy to get over that initial inertia of choosing a project, setting up the environment, etc.

Whenever this happens, I start worrying: what happened to the passion that I used to have? Why do I not have a project that I just want to hack on? Am I just complacent with the software I have, since it pretty much accomplishes what I want it to do?

To overcome the paralysis, I sometimes play little games to get myself to just start: I’ll use a random project picker that I wrote, and then work on the project that is picked for me; or I’ll listen to a podcast and pick one of the problems that is brought up by one of the hosts and start working on it. But too often, I’ll spend most of my time just getting my head around the project that was randomly picked, or I’ll move on to the next podcast (cause you can never listen to too many, right?), and nothing gets done.

Sometimes, I find that procrastinating is more enjoyable…argh.

Sometimes, I remember one of the questions that always bother me when I am actually working. But that is the subject of a future post.

2 thoughts on “Overcoming Project Paralysis”

  1. sounds like the problem can be simplified down even to making choices and sticking with them.. def easier to do something low effort/risk

  2. The problem I generally have with contributing to open-source projects is that the kinds of tasks that need contributions are almost all less interesting ones then kinds of decisions made at the start of a project.

    One suggestion I have, then, is pick an app that is simple to prototype (a to-do list, a pastebin, etc.) and then make it a bunch of times using a variety of technologies: so, for example, do it entirely in React.js and Postgresql Stored Procedures, with the minimum necessary code on the server side to connect the two.

    Another thing that’s always interesting is picking up a new language that’s weird in a way that forces you to rethink how you engineer programs. So, for example, learn Haskell (Real World Haskell is a good resource for this) or Clojure and figure out the way a language that doesn’t let you reassign variables makes you think of programs. Or, learn Common Lisp (start here http://www.gigamonkeys.com/book/ and then move to http://www.paulgraham.com/onlisp.html) and have fun learning to see code patterns that can be eliminated by the judicious application of Lisp’s code-generating macros. Other interesting avenues could be Prolog, where you write programs by expressing the logical relationships between the things you’re working with, or Forth, which is basically the most minimalistic language one could imagine that is still useful.

Leave a Reply to Wayne Cancel reply

Your email address will not be published. Required fields are marked *