4 Key Changes I Saw In Myself After My First Remote Internship
By: Gauri Dhawan
Tags: Time Management, Software Development, Remote, Engineering

Hi! I’m Gauri Dhawan, a graduate student at NYU studying computer science. This summer I interned at Optimizely as a software engineering intern. As I near the end of my 12-week internship, I wanted to share how I personally grew and what I learned from being immersed in a fully remote work environment.

I discovered that a remote-first work environment brought a set of challenges I was not anticipating, but I was excited to tackle. Working remotely comes with the benefits of having no commute and the freedom to wear stretchy pants all day, but it also requires you to practice a different communication muscle when collaborating with a larger team. Here are some key changes I saw in myself over the last 12 weeks — I hope they can help you if you’re joining a new company that is now fully remote.

Take Time to Produce Detailed Documentation

The first technical design document I wrote had to be redone almost three times until I could send it out to the whole team. While the technical design document took a bit longer, it taught me a valuable lesson around thinking from a reader’s perspective who has no knowledge of what you’re proposing and that something that might be obvious to you might not be obvious to the reader.

Writing strong technical design documents is a key skill in software engineering as it helps engineers ship features faster and more efficiently by ensuring all dependencies are documented up-front.

A few things I learned that are essential when writing technical design documents:

Be explicit about things that you assume are obvious,

Bridge the gap between the writer’s thinking and the reader’s thought process

Be able to translate your thoughts into writing.

At Optimizely I worked on a task that dealt with multiple services and drew out a flow diagram to represent the process. In my original diagram, I only documented what was happening in the flow, assuming that everyone knew what service each flow was using. By my final version, I had a clearer image that specified all the services used. The chart provided granular details so that each service and its role could be identified just looking at the diagram.

What I started with

What I ended up with

Great technical documentation and flow chart building are helpful whether remote or not. With the changing dynamics of the industry, we don’t know if the person who’s writing code today will be present tomorrow or not. Hence having detailed documentation always helps!

Communicate Clearly and Concisely

My first meeting with the team to explain one of the approaches I was proposing for my task was difficult because we couldn’t simply draw on a whiteboard. With only digital forms of communication available to me, I learned to be more thoughtful about writing detailed messages with all the necessary context upfront to make sure that I could anticipate questions and avoid misunderstandings.

Here are some of the messages I received from my mentor at the beginning of my internship — helping to direct me toward providing more context when asking questions:

Some of my slack messages

I started prefacing the question with a related topic and “the why”. Providing context in a lot of cases takes extra time, but this helps remove ambiguity and leads to a faster resolution.

Here are some examples of messages from later in my internship — now I document out the why and the additional context for my mentor:

Increase Efficiency by Timeboxing Tasks

One of the hardest parts of starting my internship remotely was having to learn about all the existing systems in the organization. This can get quite overwhelming especially when you can’t be shoulder to shoulder with someone through all the set-up. When trying to figure out a new workflow, sometimes I wouldn’t reach an answer after researching for a few hours. I was trying to be proactive and facilitate my own learning instead of just reaching out for help, but I began realizing I was sinking too much time before leaning on my team.

To help find a better balance, my manager suggested that I timebox tasks. Whenever I tried to figure out something on my own, I would spend around 30–45 mins before reaching out to someone so that I wouldn’t go down a rabbit hole. Timeboxing tasks help engineers manage their time and also keep a check on how long they spend time on each task so that they could improve next time.

Take initiative to meet Optinauts across the Org

With remote work becoming the new normal, we have to get used to reaching out to new people via Zoom and meeting them for the first time via online meetings. Having an internship to get acquainted with the new environment certainly helped me get ahead of this. I reached out to people with various asks — sometimes it would be for help in debugging an issue or sometimes it would just be to understand what role they played in Optimizely. Everyone at Optimizely was extremely approachable and a lot of people would jump in to help new engineers when they saw them struggling.

As I kept on meeting new people, my hesitation to reach out to people diminished and my network in Optimizely grew. Not only did I learn about what these people worked on, but I also got to observe their thought process and how senior engineers, managers, and leads in an organization make decisions.

Over the course of my internship, I learned four essential interpersonal skills that will help any engineer progress forward in their career. My manager once told me that anyone can code, but becoming an engineer isn’t just about coding. Engineering has several aspects to it, collaborating, communicating and brainstorming are some key aspects of engineering. I would not have been able to learn these by just doing a technical project on my own. I was glad that I had a chance to pick up these skills early on through an internship at Optimizely and fortunate enough to have mentors and managers around me who helped me build up these skills. I hope that I can continue to expand on these skills in order to become not just a developer, but a well-rounded engineer.