From the beginning of my coding journey, I’ve had a tendency to overthink my solutions. I’ve gone out of my way to find the hardest way to do things or think that the solution must be more complicated than it actually is. However, in the last couple of weeks, I’ve had some epiphanies and made some changes that have been integral to overcoming my overthinking problem.
Moving Too Fast
At this point, I’ve worked on several different coding projects, both from courses and personal projects. Throughout each of these, there’s been a theme: I move too fast. In my pursuit to be efficient, I end up setting myself back. When I try to debug too quickly, I fail to fully grasp the underlying problem. And consequently, if I need help, I struggle to ask the right questions.
After recognizing this, I read through a couple of great articles recommended by The Odin Project that helped me reframe my thinking about asking questions to myself and others. One article was on The XY Problem, which highlighted the importance of addressing the root problem rather than fixating on a particular solution. Another valuable article was on How To Be Great At Asking Coding Questions.
Overcomplicate
In addition to trying to speed run through my problem-solving process, I overcomplicate the issues. When I would ask my husband, a seasoned web developer, questions (usually about a solution rather than a problem), he would always ask, “Why are you trying to do it that way? That’s really complicated. All you need to do is X, Y, or Z.”
His recommendation is and has been to refine my problem-solving approach by slowing down, reading the documentation, starting with a simple example, then applying it to my situation, and looking for others’ solutions to the problem.
Good advice.
Slow Down and Process
It’s only been in the last couple of weeks that I’ve really put this advice into practice, and the results have been game-changing. It feels like things are finally clicking.
I’ve been continuing to work on a daily To-Do app in Next.js, and with each new function, problem, etc., instead of rushing ahead like a bull in a china shop, I stop and pause. I literally put pen to paper and start “rubber duck debugging.”
I write the problem down. I talk through the problem out loud. I talk through what I think potential solutions might be and then write those down. After I’ve taken the time to recognize what the actual problem is, I make some educated guesses at possible solutions. If I can’t solve the issue myself, I start Googling. I look through framework documentation, forums, Stack Overflow, Reddit, etc.
And guess what? It’s worked. Not only that but it’s been more efficient than my previous methods (no surprises there). I’ve solved many more issues on my own, and I’m getting a better grasp of the problem-solving process.
Building Confidence
Finally getting some wins under my belt has been a huge confidence boost. Since learning how to code, I’ve battled Imposter Syndrome. The feeling isn’t new to me, as I dealt with it when I started working clinically as an Occupational Therapist. I recognize that you must tread through the muddy waters until you reach the other side. Persevere and keep moving forward, even when faced with self-doubt, because each win will help propel you.
While I still have a lot to learn (and really, do we ever stop learning?), puzzle pieces are finally falling into place.
TLDR
Since I started learning to code, I’ve had a tendency to overcomplicate problems and work too quickly. However, in the past couple of weeks, things have started to click. When I slow down, use rubber duck debugging, and ask better questions about problems, I’ve been able to find and develop simpler, better solutions. While I still have a lot to learn, I know the key to overcoming Imposter Syndrome is to persevere and move forward, even when faced with self-doubt.