What is it?
From Investopedia, “Analysis paralysis is an inability to make a decision due to over-thinking a problem.” This often happens when there are too many options, or too many variables surrounding the options.
This happened to me this week. For our capstone project, I am making the user authentication system. The login page starts by making a request to our API. In the API, after some verification, a token is made and sent back to the user. The question I was stuck on was regarding the token. Should I send a random string, or use something like a JWT? I could pretty easily generate a random string and use that for all session verification, but I couldn’t guarantee uniqueness. A JWT could do tha, but it may be harder to set up. Do I even need to worry about uniqueness? Can I use the same middleware in the frontend and backend? Are there security concerns with either one? Is there another option I’m not even considering?
As the questions keep coming, the answer became less clear, and I was further away from a decision than when I started. The analysis paralysis had set in.
How do I stop it?
I’m sure there are many ways to overcome analysis paralysis. The one that worked for me was hypothetically picking an option, and thinking through what that would look like. I started with JWT. If I used that, I would install some middleware. Then I would probably use some function like jwt.create(token) using the user’s email address. Then I could send it back to the frontend, where I would use the same middleware (hopefully) and then decode the JWT. From my experience in Cloud Programming, I knew that a JWT could expire, so that could be a good way to manage session timeout. And the implementation for verifying that would be relatively easy.
How would it look if I just used a random string? I would probably do the same thing in the API, just with a random string instead. The frontend would take this string and save it. But what happens then? If I wanted to verify its authenticity, I would have to make a call to the API and database every time the user wanted to access a protected route. This wouldn’t happen with a JWT. If I wanted to have an expiration… well I don’t even know. I didn’t get that far in my thought process. It was pretty clear to me at this point that JWT was the way to go.
The next step was actually doing it. I sat down at my computer and started overthinking again. Lots of “what-if” questions came into my mind. But I just said screw it, Googled “node jwt”, and found a middleware that looked like it would do the job. I started coding before I could get in my own way, and after a while, I had my API successfully sending back a JWT! Was this method guaranteed to work? Of course not. But if it didn’t work out, I could have just reverted my changes and tried again.
By walking through the process of each choice, I was able to decide on the better option. I didn’t let perfect be the enemy of good. Once it was time to enact my decision, I avoided self doubt by trusting my decision, and knowing that I could always go back if it didn’t work. The next time I’m faced with analysis paralysis, I’ll remember what I did in this scenario, and I’ll be able to more easily break free from it.
