The Holy Wars of procrastination

Procrastination is putting a task that we should be doing to do later instead of now. It may be because the task seems daunting or maybe because we sometimes have a strike of ergophobia (fear of completion) and in programming there are some frequent “wars” we tend to fight with the pretext “this is important before I start”.

This articles comes because I see a lot of awesome projects, mine and otherwise, never being finished because the wars that end up being fought with ourselves and colleagues are in most cases a form of procrastination.

Create that great ideia you have on your head instead of being idle by fighting wars that have no end goal.

To name a few, and some possible solutions, here were we go…

IDE war

This one occurs specially in teams to choose what IDE to use, VS Code vs Atom, Intellij vs Eclipse, vim vs emacs, and so many others. These take a lot of development time at the start of a project because everyone has a favorite and those who don’t don’t know what to use in the mist of all the arguments.

If have no clue of what to use do a quick search for what IDE supports the programming language you want to use “out of the box” and start learning it has you go, don’t get stuck with add-ons configurations and learning every feature from the start.

When on a team just decide which one most people are comfortable with and go with it, you can keep using your favorite one most of the time, you just have to keep the one that everyone agreed at the start at hand and configured just in case you have to do some pair programming.

Syntax war

“I use tabs and not spaces”, “No ; at the end of a expression”, “I rather use “ than ‘ ”. I see this kind of arguments all the time and at my current job every project has a different style guide defined.

What we ended up noticing is that “consistency is key”, you can adapt faster than you think to a style guide that you are not familiar with you just keep a linter for each project.

If you’re having problems fighting this war by defining a style guide from scratch just use already existing ones, in case of javascript google’s or airbnb’s work like a charm with eslint running to check the files. You don’t need to leave it “has is”, adapt it to your preference has you start coding your project, in case of a team, with the feedback of everyone, if a rule is not fitting just discuss it when you’re having problems with it, maybe the rest of the team is on the same boat and it ends of being ignored on the linter.

Over-engineering war

“I’m gonna do a calendar app with react…oh…I read that I should use redux, or maybe MOBX….I want to use ES6+ so maybe webpack along the way…I’m adding that cool thing, what was it…oh…yes GraphQL, so maybe I should use node on the backend and Grunt and PostCSS and Tape for testing, or enzyme, maybe I also install Yarn since is faster than NPM….almost forgot, should add I will add typescript since that way I will have less problems from what I’ve read, and….”

I think I made my point that, specially if your not familiar with those tech libraries/frameworks, 2 weeks later you will still have a Hello World and few else (if not, congrats!). Most of the time is better at the start of a project to keep with what you know plus 1 or 2 new libraries/frameworks that way you will see progress in your project and will learn new stuff nonetheless.

Any “extra” libraries aside from those 1 or 2 you choose at the start can be added as you have the need for them, you will know you have the need when the thought “this is repetitive and has to have a way to be made better” is starting to be frequent has you develop your project.

Perfection war

“The project is not perfect yet, I have 100 more ideias, I have to add tests, need to have CI, need to…”

Same old same old, the fear of something we make being judged sometimes leaves us to endlessly add features and never releasing with fear that someone will not like it because that one feature that we add on our head was not sent from the start.

Perfect is the enemy of good, it’s better to have something good being used and improved than having something perfect just stuck in our heads or computer.


  • If you are working on a team, choose an IDE that fits most people, most of the time you will use your favorite tool, just keep the one that everyone agreed upon configured like the rest of the team just in case you have to do pair programming or something of the sort;
  • Choose 1 or 2 new frameworks or libraries to start your project alongside the tech stack you already are comfortable with, that way you will not be stuck for hours without end trying to understand 30 libraries you would like to know and think are necessary for the development of your project. This will make the project evolve more naturally and you will see faster progress;
  • Choose a syntax and adapt it as you go, it is hard, if not even impossible, to know before hand if style guides like google’s or airbnb’s will fit completely to your needs/habits;
  • Create an MVP and just add future features to a “up next” list of sorts, unless it is really critical to whatever you’re developing, most of the ideias you will have along the way are “should have” and not “must have or this project will go nowhere” it will only go nowhere if you never ship it.

While it is important to fight this wars before the start of a project my point is that you should not overthink it, start doing whatever you have on your mind and learn has you go, adapt, but stop fighting wars that at the end, will only waste your time.

Now that you’ve finished reading, leave a comment, follow me at @daspinola and go get that brilliant project of yours on the way!