Hi, I'm Marc and this would be my first article in dev.to. Like you, I'm passionate about working around technology, particularly software development (specifically, backend). I've been learning through tutorials, massive open online courses, books, and online articles, just to name a few. I've been learning for years and I thought that my skills should be validated.

Last August 2020, RightValley, a tech startup, opened a remote software development position. Though, that time, we are not yet scheduled to have our academic internship, I still applied and fortunately, I got in. I learned a lot of technologies like flutter, graphql, django-saleor, react, agile-scrum methodology, etc. but what I'm going to share in this article are not these technologies but lessons where I experience 'AHA!' moments and lessons that I believe I will not get from any tutorial but only through experience and mentorship.

Lesson 1: Use the debugger

I know the use of the debugger in my IDE but I really didn't use it because I see no issues with the print statement. Tutorials, even books from known publishers even use the print statement to demonstrate errors in a program. My mentor suggested that I should use it. After that suggestion, I worked on a new task, a logout feature, which I thought was pretty easy. I got an idea in mind which is to just clear all the user data with the logout button in my flutter app. At first, it worked, but the app had weird behavior. It behaves as if the user is still authenticated. In this situation, all of my print statements confirmed that all user data were cleared. Being left with only one option, I desperately used the debugger. I properly set the breakpoint and run it. After clicking the logout button, I investigated it with the debugger's step into and step over feature. It was the authentication token that was not cleared. The debugger was a great help and since then, I committed that I should really use it.

Lesson 2: Understand the framework's architecture you're reverse engineering

In my internship, we reverse engineered a massive e-commerce framework, saleor. I got a task to add some API functionality. To solve it, I inspected saleor's source code for the first time and I got easily lost. The behavior of the code I was seeing was unknown to me and I even got nervous if I can finish the task on time. Having the dedication of taking the ownership of the project, I traced what does the code do and how does it behave when some of its code is missing. Understanding the code of the framework allowed me to finish my task. After that, more similar tasks pile up. I can't imagine myself solving those task if I didn't try to understand saleor.

Lesson 3: Read the docs, carefully

Sometimes, exact answers from stackoverflow or youtube videos saves time because the answers to problems are provided and it's assured that it is working when you see that green check mark on stackoverflow or when the demo on youtube is working. But what about when you encounter problems that you can't seem to find the solution on the internet? The docs can give you answers and you get them right if you read them carefully.

I will tell you an example scenario when I had an error in my flutter app in which I got a hard time in to come up with a solution but can be fixed in a few minutes. When I was integrating a graphql mutation in my flutter app, I got an error that tells that there's something wrong with my mutation. I checked the graphql-flutter docs and I confirmed that my mutation was properly set up. I also checked the API from saleor docs and it's exactly the one that I copy and pasted. Having no similar questions in stackoverflow or guides on youtube made me hopeless. I tried to reread both docs for the second time, more careful just to be sure I don't miss all the details. I noticed that the API I copied from saleor should follow the format that the graphql-flutter showed. I fixed my problem and it taught me in a hard way to read the docs carefully.

Lesson 4: Think about and write the algorithm before you code

I realized that it is faster and more convenient to code when you have an algorithm in mind. Once the problem in my task is identified, I analyzed what should be done and I wrote the algorithm (of course it's pseudocode) in paper, sometimes in my text editor. The only thing left that should be done is to code the solution. Personally, it is more enjoyable to do this since the analysis phase is already done. Analyzing and coding at the same time, without the guide on my paper, led me to being paralyzed on my screen especially for complex tasks.

Lesson 5: Gitflow

When I was learning how to use git, almost all articles or tutorials that I encountered show how to add, commit or push code, basically showing a series of steps on how to use it. In my internship, we were taught about gitflow, a workflow that defines a branching model for git. Basically you have a 'develop' and 'master' branch. You also have branches for features and bug fixes. I won't talk about it in detail but I must say that a software developer should know it. Developers work in a team and gitflow greatly helps in collaboration.

Conclusion

I was so eager to experience building software for a client's business in order to validate the accumulated skills I got from non-stop learning through books, blogs, and free online courses and video tutorials. Being a software developer intern gave me such fulfillment and also made me realize one thing: Learning is not only achieved through books, online courses or tutorials and articles but also through mentorship and experience. I hope I can learn more once I have my official academic internship and as well as apply those lessons I learned from my previous experience.