Embracing Structure, Overcoming Doubt, and Finding the “A-ha” Moments in Coding
For the longest time, I’ve felt like I’ve been stuck in the present—not in a mindful, “live in the moment” way, but in a way that has kept me from moving forward. My lack of financial resources and security has made me hesitant to take risks, experiment, or even think long-term. But lately, I’ve realized that this mindset is holding me back from the very opportunities I need to create that security. So, I’ve been taking small steps toward consistency, growth, and, more importantly, structure.
For the past two weeks, I’ve been pushing myself to get back into problem-solving mode by tackling LeetCode problems again. Yeah, I know—it’s the “FAANG gatekeeper” that everyone dreads. But I’ve chosen to do it anyway, not because I want to grind for a big tech job (though I wouldn’t mind one), but because I recognize that my approach to coding needs improvement.
And here’s an insecurity I’ve been holding onto for a while: I don’t think I lack knowledge when it comes to coding—I lack structure. My thought process feels scattered, like fragmented data that needs a serious defragmentation. The knowledge is there, but when I sit down to write code from scratch, I freeze. It’s not the logic that trips me up; it’s the funny nuances like naming classes and methods, structuring Object-Oriented Programming (OOP), and making sense of what should be intuitive. It’s frustrating, and it’s something I know I need to work on.
Finding Structure Through Practice
One of the LeetCode problems I worked on recently was 2379. Minimum Recolors to Get K Consecutive Black Blocks. It’s a sliding window problem, and when I read it, something clicked—I had seen this concept before, whether in real-life problem-solving or a video game. But when it came to writing the code, I struggled to get the implementation right. I needed building blocks.
This made me realize something: In technical assessments, companies want to see how you solve problems—not just copy-paste solutions from AI or Stack Overflow. That means you have to go through a certain rhythm or “cognitive beats” when approaching a problem. When I broke the problem down and structured it properly, I had an unexpected “A-ha!” moment.
Here’s what helped me gain that clarity:
- Using clear, descriptive variable names like
min_changes(for the minimum changes needed in the sliding window). - Setting up an initial condition with
current_changes = min_changesto keep track of the lowest possible changes dynamically. - Recognizing that sometimes, the best way to approach a problem isn’t to brute-force it, but to break it into smaller, logical components.
And just like that, coding became fun again—not because I mastered the problem in an instant, but because I finally understood the process behind it.
Moving Forward: Embracing the Challenge
This experience has reinforced something important for me: I need to practice more, but more importantly, I need to practice with structure. Coding isn’t just about solving problems—it’s about how you approach them, how you think about them, and how you communicate your solutions. And this applies beyond just technical assessments.
Opening yourself up to more opportunities isn’t just about applying for jobs, networking, or hoping for a lucky break. It’s about making yourself ready for those opportunities. And for me, that means:
- Building structure in my coding process so I don’t freeze when I start writing.
- Developing a methodical approach rather than relying on scattered knowledge.
- Practicing consistently so that my problem-solving becomes second nature.
- Embracing the fun in the challenge rather than seeing it as an obligation.
This is just the beginning, and I’ll be doing a more refined breakdown of my coding journey in future posts. But for now, this is my confession, my brain dump, and my realization that I can—and will—move past my current limitations.
I’m opening myself up to more opportunities, and this time, I’m ready to embrace them.
What about you? Have you ever felt stuck in your own head when it comes to coding or problem-solving? What strategies have helped you overcome those moments of hesitation? Drop a comment—I’d love to hear your thoughts!