The Start

For me the most difficult part of starting something new is taking that first step and committing. It doesn't matter if it’s a new hobby or developing a new feature in the code I write. The first step continues to be the most difficult.

I don't remember having these issues during school or college. Sure, some things might have been last minute, but that was a different problem, a problem of waiting, procrastinating. I could still get the tasks completed, hitting most of the rubric and getting a grade that was always fair for work being put in. Procrastination is a different problem than overthinking though. I wasn't worried if I didn't score high marks on an assignment, that was temporary and low stakes. As we all know though, the wrong implementation sinks projects. If the perfect design is used, then you'll save so many headaches, right? Loose Types sinks ships after all.
That’s the problem, chasing perfection. Thinking that it'll prevent nasty problems from appearing. Working in Quality Assurance, I saw firsthand what rushed implementations produced, and it was projects that were a slog to work with. Producing features and squashing bugs always took longer than expected. I wasn’t going to make the same mistake when I developed. To date I’ve been able to setup automation and haven’t had to use an existing solution. In doing so I have had to work with my own implementations and learn a lot along the way. What continued to follow me is the implementation paralysis, the self-imposed burden of excellence in creating systems that would not only cover my immediate use case, but also a handful of other potential use cases. The paralysis built as I progressed down this list:

  1. See issue A
  2. Design for issue A, B, C
  3. Begin implementing
  4. Get overwhelmed during the implementation
  5. Go do something else
  6. Comeback to Really crack out the implementation
  7. GoTo 4

Overtime the solution does get implemented due to a mad rush at the end, or overtime due to small chucks completed between cycling from 4 to 7. This pattern is present in other things as well, like trying to set this site up:

  1. Have idea to setup site
  2. Get site mostly setup
  3. Sit down to write the first article
  4. Decide to keep working on the site code till it’s perfect

I am still working on the habits and implementations to turn around my implementation paralysis. What helped the most is the idea of incremental improvement and that anything produced is better than nothing produced. It changes that paralysis list to:

  1. See issue A
  2. Design for issue A
  3. Implement

Now I create code that is less extensible, but most of the time it doesn’t need to be. I revisit areas of code more often, but that just means that I need to add features that I didn’t need before. I spend more time implementing, and less time overthinking. Just in time for this post.