One thing that is always hard when you’re new to something is knowing how to get started. When I try to learn a new language or library, I often get analysis paralysis because I have no idea what is the right way to do things. I can instantly imagine the way I’m organizing my project or writing some code is the beginning of a huge mistake that will be painful to sort out later. Contrast this with starting something in an environment I know well. I might have some templates ready to go and I can immediately start writing code. All the little decisions, that paralyze me at first, become non-issues over time. But how does that happen?
The key is to get started, but that minimizes the challenge in overcoming those internal voices telling you you’re doing it wrong. Programmers often have fear that some decision is going to be forever and you can never change anything ever. Beyond the efforts being wasted, you create dependencies that you’ll have to maintain or else everything could break. These voices telling you you’re wasting time or energy are very convincing, but I’d argue they are wrong.
As a programmer, you need to deal with change. No software is ever finished, yet we are often deathly afraid of rewriting some code. Most programmers will eventually come into contact with legacy code that has an impact on how they believe software should be written. They see some pattern or technique and how it evolved into a big blob of confusion. They swear they will never make that mistake. In reality though, that pattern or technique was probably just fine at one point. Sandi Metz has a great blog and talk about dealing with the wrong abstraction . In the article, she mentions that most of the time we avoid change because a fear of the sunk cost. Overcoming this fear is critical in order to embrace change.
Embracing change also means it is easier to start. The wrong decisions you make can be fixed, so you might as well start with something small. Worst case scenario, you start from scratch, which isn’t really that bad in the first place. This obviously takes practice, but starting something is a great way to practice.
I was reminded of this as my deliverables have changed from code to documents and process. I had a specific planning document I needed to write and it was daunting to start adding things to some template. I chose to start writing it in my trusty Emacs with Org Mode. It was interesting to see the 20 minutes I spent putting down my ideas in plain text translated to me quickly transitioning over to a google doc and getting it done. I just needed to start and embrace the inevitable change.