5 Lessons From My One Month Remote Software Engineering Internship

Shannon Kariuki
5 min readSep 14, 2020
Photo by Akil Mazumder from Pexels

2020 has been a rollercoaster ride for me as a new graduate. The karmic gods decided that the perfect introduction to adulting would be a pandemic, social and economic strife, and apocalyptic fire brazen skies. Yipee! My friend called this season in our life baptism by fire and I could not agree with her more.

However, one of my highlights of this murky year was the opportunity I had to intern remotely at Chartyn, a startup that provides AI-driven business insights for their clients. This was my first software engineering internship and I was excited to work on real-life code that would serve clients and not just my own personal projects. Although the internship was brief I got some great takeaways about how to be a successful developer. Here are the 5 lessons I learned from my one-month remote software engineering internship.

1. How To Upskill

I was tasked to design and implement a search interface for searching through existing data streams to be analyzed. This would help clients find their connections easily without having to scroll through the whole page to find what they are looking for. The U.I is built using Vue.js and it was my first time working with Vue.

As a developer one is expected to pick up new languages and frameworks to fulfill the requirements of the project assigned. Therefore, learning how to quickly upskill is a crucial skill to develop. To learn Vue.js I spent the first couple of days reading through the official Vue documentation (which is so well written and easy to digest). Because I have some experience with React I was able to pattern-match and identity the similarities between the two frameworks. If you zoom out, you will notice that frameworks are just different approaches to implementing a core concept. In the case of React and Vue, organizing code into modular and reusable components is the core concept. Everything else is mostly syntactical differences. Once you see and understand the bigger picture, it is easier to zoom in and pick up the differences between what you already know and what you are learning.

Another lesson that I learned and will continue to develop is the ability to read another person’s code. Programming should be looked at like any other language where you become better by not only being able to write it but also by reading and speaking about it. Like any new developer, I was intimidated by working on an already existing codebase, and it took a while to understand how the code was organized and why it was organized that way by the other developers in the team. But the best advice I can give myself and other newbies is to just go for it. Don’t spend too much time reading the code and being afraid of where to start. Just jump in, break something, and rebuild it. Best way to make progress as a developer is to read code — break it — and rebuild it. In your first 6 months as a junior dev, you most likely will be working in a production environment and will not likely be deploying code to the main live codebase so the risks are relatively low for the reward of getting your hands dirty and building and breaking the code to fully understand what you are doing.

Don’t spend too much time reading the code and being afraid of where to start. Just jump in, break something, and rebuild it.

2. How To Linux

The first week of my internship was a hassle of having my laptop configured appropriately so that I had access to the code base and could push changes to the remote feature branch. The configuration documentation assumed a UNIX environment but I have a Windows OS. So at first, I tried to use Ubuntu on Oracle Virtual Box but kept running into permission issues to write to the shared folder, so I opted to use the Windows Subsystem for Linux (WSL). I learned a lot about the file system, writing, and using scripts and the power of Unix in general. Every developer should have Unix in their toolbox even if you are not a system admin or back-end developer.

3. How To Document

Throughout the internship, the lead dev - and overseer of my project, and I communicated through a shared Google Doc where I wrote what I was working on and my progress so far. We also used the doc to keep a record of questions I had and the answers he gave about things I was struggling to understand.

Honestly, documentation is tiresome and it can feel like it is taking away time from the ‘real work’ but it is crucial to keep a written track of what you are doing as it will not only benefit the present you but also the future you and everyone else who will have access to the doc.

Learning how to properly document your work is a muscle you develop with practice. That is one of the reasons I am taking the time to reflect and document what I learned in this article. I am a big believer in practicing in public, even if it is messy, instead of refining your skills in private for a big polished reveal in the end.

I am a big believer in practicing in public, even if it is messy, instead of refining your skills in private for a big polished reveal in the end.

4. How To Refine Your Developer’s ToolKit

The lead developer in the team gave this analogy of how to compare my daily work as a developer to that of a surgeon’s. A surgeon’s day is not only compromised of performing the actual surgery but also of prepping for the surgery by checking her tools, talking to the patient and nurses, washing her hands e.t.c. If her work environment isn’t properly set up then her performance is compromised. In the same light, a developer has to invest some time in optimizing her work environment. This includes configuring your IDE with proper linting, configuring your terminal with some syntactic sugar e.g setting different text colors to indicate whether you are in root or home so that you don’t accidentally perform a root function thinking you are in your home directory. Small things like these may not be directly related to the heavy work of working on your project but it does optimize your work environment which will optimize your performance.

5. How To Code Review

The code review process was intimidating for me as a new dev, I felt my imposter syndrome rearing up every time I was ready to push my code to Phabricator (a code review tool). Is my code ready to be seen by my supervisor? Have I worked on enough code today or is this too little work to show? These are the questions that I would ask myself before pushing my code. However, I learned that code review is part of a developer’s learning journey. It helps keep you accountable to somebody else who will look at your code. It also gives you a chance to communicate why you implemented your code the way you did. Unless you just have a mean code reviewer whose criticism is just out of spite, any feedback given should be taken as a chance to learn and grow.

--

--