Hello devLOVEpers!

Its been a long gap since I wrote my last article here. Due to some busy schedule in my personal job, I was not able to extract some time for it.

Today I wanted to discuss with you something that is not related to coding but is related to the process of software development. It is something about decision making as a programmer. Basically decision making plays a vital role in every coders life; let it be - what kind of design to choose, what logic to use to achieve something, whom to ask help and the list goes on. Simply saying, from writing a simple if condition in your program to delivering that project, there are lots of decisions you need to make.

Especially if there are no deadlines set for what you do, there is a high probability for you to get trapped in this ambiguity of decision making. This phenomenon is often referred to as 'Analysis Paralysis'

According to Wikipedia, the actual definition of Analysis Paralysis is -

Analysis paralysis (or paralysis by analysis) describes an individual or group process when overanalyzing or overthinking a situation can cause forward motion or decision-making to become "paralyzed", meaning that no solution or course of action is decided upon.

• Analysis paralysis happens when over analysis or overthinking prevents an individual or group from making a decision.
• This phenomenon can occur when an individual is unsure of the best method for reaching a decision.
• In software development, analysis paralysis can lead to unnecessary confusions.

Tell Me a Story!

Let me tell you a story so that you can elate this to yourself. There are three kids aged 8 and under and one of them, the oldest boy B, has a bit of a problem. Whenever they go out (to eat dinner, to get ice cream, even to rent a movie), B spends agonizing minutes flip-flopping over which flavor is better, which drink he really wants, which film he wants to see more.

His friend finally decided to ask him why it's so difficult for him to make a decision like this, and B told him:

"I want to pick one, but part of my brain is telling me, 'But what if I'd like the other one better?'"

Poor B often finds himself stuck in analysis paralysis. To him, being a child, the choices presented are often vast, daunting, maybe even a bit scary. It is entirely possible that he would like the other choice better, but he cannot know that until he makes a decision.

It is exactly the same with grown-up, real-world analysis paralysis: sometimes, you cannot know if you'd like a different choice better until you've made a choice.

When Does This Happen?

There are two distinct modes when programming: hacker mode and engineering mode.

In hacker mode, you don't run into analysis paralysis. You are going in a straight line path towards your vision of the product, even if the straight line leads through mud. The danger here is that you might run into major design flaws and dead-ends and have to throw away a lot of code -- perhaps the whole thing, perhaps even before you have a prototype. If you do make a prototype, it's likely to have many problems as you try to turn it into a releasable product.

In engineering mode, you aren't going to make any real blunders. When you know what to do, you'll hit that estimated delivery date, maybe +10%. It will scale nicely and be fairly secure and predictable. The dangers here are that you might lose sight of the use case (if you even have one), or lose other big picture context; or you might suffer from analysis paralysis and not do anything.

Recognize which mode you're in and what the dangers are. If you're suffering from analysis paralysis, the cure is to switch to hacker mode for a short time. If you're having trouble doing that, perhaps you don't have a real use case -- maybe you just heard about a cool new technology and you were looking for a project to do. Step away from the technology and get creative again.

Some simple ways to stop analyzing and start doing

Ok, so we know from science and experience that overthinking a decision increases anxiety and kills your productivity, but what can we do about it?

1. Structure your decisions

If you start building something, try to breakout the requirement into different small pieces which include one or very few decision to make at every part. Its ok if the very first approach is not a good one.

2. Understand that programming is a Trial and Error process!

What ever you want to achieve in programming, there is a lot of failure stories behind it. So, simply if some decision that you took is not working out, take it easy, its how programming works. You can always switch to other process.

3. Intentionally limit the amount of information you consume

What I mean by this is, if you are searching for a solution for a particular problem that you got stuck, we usually open dozens of chrome tabs of different solutions. Due to this, you are in turn confusing yourself by looking at different approaches. Determine the number of resources you’ll use first. Make this strategy even more effective by limiting yourself to only those number of tabs.

4. Set a deadline and hold yourself accountable.

Parkinson’s Law states that work expands to fill the amount of time you’ve allotted it. If you give yourself an hour to do a task, it will take an hour. If you give yourself 15 minutes to complete the same task, it will take 15 minutes. The same holds true for making decisions. Setting a time constraint can force you to make a decision more efficiently.

Tell a coworker or friend who will help to hold you accountable to your decision deadline, or even commit to a deadline on social media.

5. Know your main objective.

When you encounter a tough decision, avoid analysis paralysis by asking yourself which option aligns best with your most important goal or value.

6. Discuss with peers

If you stuck at something, don't try to be in a mindset of solving it anyway. Seek help. Ask your teammates and discuss with them whatever is there in your mind. In that way you have opened a door of probable solutions.

Conclusion

The history of programming has shown time and time again that we NEVER know everything that we will be asked to do. You deliver what the customer asked for and then they ask for a slight tweak. Or a dozen.

No matter how you try, you cannot possibly get it perfectly correct.

So, do what you can, and then ship it. Don't worry, they'll be back with bugs and requests galore.