What color is your Text Editor?

The beauty of Vim.

Some of the biggest questions I had when I started developing were about choosing which tools to use. Questions like what text editor or ide to use, which framework to learn, which language to learn, which paradigm to program in, and even what type of project to build were constantly holding me back from working on projects and attaining coveted github green.

At the time, I lurked a lot on Hacker News, reading about the latest applications built with a “new” programming paradigms and learning each week’s new Front-End Javascript framework.

The choices available to the development acolyte are overwhelming. It seems impossible to make these decisions, and whenever I ran into problems using certain technologies in my side projects, I wondered whether or not I should “start over from scratch” and redo whatever I was working on in the newest, hottest framework.

Because of the massive number of choices I had to make, I often found myself at a loss as to what to choose.

Decision Paralysis

When you just can’t decide.

I once heard that when humans are presented more than two or three choices at a time, it becomes too difficult for us to make a decision and our brains shut down. In response to shutting down, we feel overwhelmed and either don’t make any decision or simply choose to do something else (like binge-watch the new season of Narcos on Netflix).

Nowadays, with choices beating down our doorsteps 24/7, we cannot escape choosing. It is the job of every software developer to find tools and environments she enjoys using and to build the skills required to use them effectively.

The way to start fighting Decision Paralysis is to realize that every big decision is full of small, binary decisions.

The hard decision, “Which framework should I use to build my new app?” for example, can be broken down into smaller ones. Instead of asking yourself “should I use the newest framework in my personal project?” You should ask yourself a number of smaller questions:

1. “Do I want this project to be used to learn, or to try and make money?”
2. “Have other people built successful projects in this framework?”
3. “Does the framework support not just the building of the application, but also the cognitive cost related to maintaining the project in the future?”
4. “Do I think the framework will be supported by the community for awhile, and I will not have to rewrite the application in a new framework in a couple of months?”

Then you can ask yourself a number of follow-up questions about your project:

1. “Do I want to start trying to bootstrap this application and make money quickly?”
2. “Do I really want to take the time to learn the new framework (or language) or simply develop features in something I already know to build a customer base?”

After you have answered these smaller questions, you will probably have your answer as to whether or not to use the framework you were looking at in your project.

Don’t listen to what everyone says is the best framework or language out there. Choose one you’re personally interested in that matches your goals. If you don’t like it after a while or if your side-project goes stale, and you’re not working on something that already has a large customer base, ditch it and work in something different. Even if this happens, you’ve made a decision, and any decision pushes you closer to your goal.

But what if I choose the wrong thing?

I have a secret for you.

There is no wrong framework/language/IDE.

There also isn’t a “right one.

Some of the best open source developers use Sublime Text to write beautiful software. Some of the newest devs are vim or emacs wizards — constantly modifying their workflow and finding the plugins that work best.

Some senior devs who build systems millions of people use every day are writing code on WebStorm or IntelliJ.

The tool you choose really doesn’t matter, but because everybody wants you to use their product, they will tell you it’s the best one.

One quote by a blogger whose name I forgot I said it best:

You can write great software in any shitty language you want. Because they all are shitty in some way.

Make your decisions based on your interest and what works for you, regardless of what anyone else tells you.The only criteria for winning this game is that you build something.

But what should I build?

This guy knows how to build.

Everything. Build all the things. Start some projects, then quit them, then return to them later and finish them.

Learn about architectural decisions and how to set yourself up to code into the future, but don’t over-think every decision you need to make. Make many mistakes, feel inadequate, and learn to build software through those feelings.

Find fun projects that excite you about being an engineer and build them as far as you can.

Keep writing software and learning new things even if you fail or don’t get the results you originally thought you would.

This method works because the time you spend coding, interacting with the computer, and learning will accumulate and solidify who you are as a programmer.

One of the coolest things about enjoying the process of writing software is that once you have a basic grasp of the skills of programming (which can take anywhere from three months to two years), you are employable, and you can live at least a middle-class lifestyle nearly anywhere in the world.

There aren’t many other careers where this is true. As a developer, you can get paid to learn about and do what you love. Just make sure you do what it takes to keep loving it.

Build the software of the future by doing what you love today — one function declaration at a time.

Don’t forget to share your text editor themes in the comments!