When I started learning about programming, I knew someone good at it. Effortlessly solving any programming challenges they faced. Several people acknowledged them as one of the best programmers they knew. I always noticed that this person never once reached out for help in any programming related problems. It made me think that becoming a proficient programmer meant that you were self-sufficient in addition to rarely facing any challenges.

I now know this to be completely wrong. There were over 32 million results available when I Googled “Struggling with programming”. Also, several blogs were available to help out anyone facing this issue.

In my last blog, I mentioned that one of my core values is seeking challenges. I am bound to struggle often. Seeking challenges itself is a struggle. Putting myself in an environment that I am not familiar with mentally or physically is daunting. The converse being, choosing to stay in my comfort zone, with my knowledge sheltered. Which will eventually impede my learning.

When I began contributing to Public Lab, I remember putting this core value into use. I challenged myself to tackle an issue that scared me.

I kept thinking back and forth on whether I should reach out and pick the issue. What if I failed at it? What if it was too difficult? What if I took too long? These were questions running through my mind. Also, I was applying to become an intern with Public Lab. What if the work I delivered showed them that I was not the right person to pick as an intern? The questions continued.

Sometimes you have to silence that negative inner voice and take a chance on yourself. That’s what I did.

I was not familiar with how Public Lab works. Furthermore, I was not knowledgeable about the codebase. First, was figuring out which page I was to work on. I did some research on my own but wasn’t sure and decided to reach out.

I never felt like I was a nuisance by seeking clarity. My queries were welcomed and addressed respectfully. Kudos to the Public Lab Community!

The first question led to other questions. It was like slowly solving a piece of the puzzle.

With all my questions answered, I decided to work on the issue and raise a pull request. Which also created a lot more questions. The more questions I asked, the more I learnt about Public Lab and the codebase. Solving part of my original challenge.

Once I raised the pull request, I quickly saw the tests failing. I tried rerunning the tests as well as confirming whether the test was written correctly and it was still failing. I reached out for help by explaining what was expected and what was happening because I knew I was struggling to fix it.

This lead to a discussion of various ways I could fix the issue. A learning point for me, in case I encountered the same problem in the future. The feedback I received eventually led to the tests passing!

My solution was accepted, with a lot of revisions from the feedback I received from the Public Lab maintainers and reviewers which improved my code. You can have a look at the preview button I worked on here.

The questions I have had to ask about Public Lab since then, have not reduced. Once, I found myself writing a very long question to post on the communication channel. Midway through my question, I found myself realizing the answer. I think it was the fact that writing the problem down made me think about it differently.

Everybody struggles. I keep forgetting this statement a lot especially when I am struggling. The statement itself is not to minify your struggle and make it seem as though your struggles do not matter, which might often be the case with generalization. But it is meant to help you know that the challenges you face are not unique to you, and that other people have gone through similar challenges as well. Validating your struggle. Embrace the struggle! I promise you’ll learn a thing or two.