Everybody Struggles!

            Everybody Struggles!

Hello! This blog is part of the series of blogs I am writing during my Outreachy 2020 summer internship with Intermine Boot project in the Intermine Organization.

No matter how experienced or novice a person is, everybody experiences struggle at some point in their journey. The statement seems pretty easy to admit to many people. But when you are a beginner stepping your foot in the mammoth field of software development, it’s very difficult to acknowledge that even your mentors or other senior developers would have ever struggled at basic problems like you do. This gap in acknowledgment creates an inferiority complex and makes your journey to the top much more difficult than it should be.

Today, I’ll be sharing one such incident where I was stuck on an issue for quite a long time just because I was hesitant to ask someone else. As you read on, I’ll recommend to ignore all the technical jargon in the coming paragraphs if you don’t get it as that’s not essential to the point I want to make. There can be a lot of similar situations.

I am in my third week of internship with Intermine. I have been doing some form of coding for the past 4 years or more (mostly as part of my course curriculum) but I am still very much a beginner in most of the domains. Giving some context to the following discussion, the intermine_boot project is a command line tool to ease the building process for the Intermine instances. It fetches an already built docker image or builds a docker image if needed and runs docker container with the image to get the intermine instance running. I was working on a task to modify the build file for a docker image in such a way that a new image is only built if a build folder does not already exist on the system. To test the changes, I’d have to run the intermine_boot command in such a way that the rebuild of the image is triggered and I can see if the changes are taking effect. My mentor, Kevin, gave me instructions on how to test this. The instructions, although clear, involved a number of steps out of which one step wasn’t clear to me even after going through the explanation multiple times. The fear of asking a stupid question kicked in and I thought I’ll just go on with whatever I understood.

I started my 16 hour long journey to debugging my changes by modifying the code and testing the functionality. I followed the instructions and tested my build and it failed (obviously, as I was missing that piece). I searched the error online to no and landed on some stack overflow results. I tried to make the suggested changes without understanding them and it resulted in other errors. Finally, I gave up and took a nap for the second time. After waking up I was attaching the errors in a message to ask the mentor again. But, voila! When I started putting all things together during asking I realized the fix that could be useful and it worked. I realized that I had become frantic and started trying a lot of things without understanding them.

I took-away the following lessons from this incident and consciously try to follow them.

1. When you don’t understand what the other person has said, don’t just assume that you will figure it out. Just ask him again to clarify and that will save you a lot of time.
2. When stuck on an issue, you can become frantic and trying random solutions. Just take a small break or nap and see the magic.
3. Don’t code before understanding what you are trying to do. It’s a recipe for failure.
   

The Struggle you are in today is developing the Strength you need for tomorrow

– Robert Tew