---
tags: career development
---

# A Reflection On My Summer 2019 Internship
[TOC]
## Introduction
**This is a paste of my internship reflection written in Fall 2019. I deleted the note about a year ago, but decided to upload it again to re-start my notes.**

On August 9, 2019, I closed out my Summer 2019 internship at [IBM](https://www.ibm.com/us-en/). I'm glad to have recieved the opportunity to intern there for my first software engineering internship because I learned a lot about working in the industry and how it contrasts with my academic experience. I wanted to note down the insights I drew from my experience to serve as a future reference on how I have grown as a software engineer and a guide for anyone who would like to learn from my accomplishments and failures.

## Lessons and Relevations
### It's difficult to stay satisfied with front-end work.
**Context:** This summer, I was placed in a front-end role, implementing features for views in an internal dashboard. One thing I came to realize was that one feature requires various opinions and a surprisingly complicated series of steps to bring to fruition. Often time, even if I was done with the functionality, I would consider the visual design and usability of the feature and realize that there were several other tasks that needed to tackled.

**Takeaways:**
* **Ask more questions.** An initial obstacle of mine was asking the right questions to make sure the feature met the expectations of my manager and team lead. In the beginning, I came up with many of the designs myself and wasted precious time making sure they were "perfect". Some of them were approved, but a good portion of them required many iterations. This is a stark contrast to most assignments in academia, which have clear guidelines and hint at relevant concepts to achieve success.
* **Don't obsess over low-impact details.** I had a perfectionistic streak with some of the tasks assigned to me. I would obsess over design fixes that would improve user experience, but were considered too low-impact compared to a functional new feature. I remember having a couple features to implement and a mountain of design fixes I assigned to myself to go along with them. By the end of my internship, I was struggling to finish all of my tasks and making these new features functional.

### Changes happen, but communicate often.
**Context:** Over the duration of my internship, the requirements assigned to me would shift. In each case, I had to refactor my code to meet the new requirement, which would hinder my progress on my other tasks. I would like to note that this is perfectly *okay*.

**Takeaways**
* **Update my team members and manager more often.** If I could have done anything differently, I would have scheduled a meeting with my team leader and manager to discuss the requirements they assigned to me to make sure everyone was on the same page. Changes happen and that's *okay*, so I should inform my manager as soon as possible that my other tasks were delayed.
* **Practice estimating the time it takes to implement a feature.** In industry work, there are deadlines and it's likely you'll have to estimate how long it'll take to finish a task. According to my coworker, the estimation should be based on how long you think it takes to finish + 1 week for bugs. Now the real struggle is estimating how long you think it takes to finish. As I mentioned before, implementing a feature requires being able to break it down into concrete steps that you can treat as milestones. This provides a good guideline for estimating progress and how much more time it would take to finish a feature. If I could have went back, I would have written out a complete task list for self-reference before giving an estimation.

### My work has impact beyond my internship.
**Context:** Coming into my internship, I expected to be held accountable for my assigned project. Upon reflection, I think I did good job of taking ownership of my project, but could have improved on handing off my work.

**Takeaways**
* **Work on the quality of the code I leave behind.** One of the first challenges I faced was understanding the legacy code enough to be able to contribute to the existing codebase. The lack of documentation made it difficult to efficiently comprehend how the author intended for the code to work and it took several days of going through "callback hell" to get to the point where I could start coding. I took my initial struggle to heart, realizing that it was important to focus on making my code readable. Another temptation I grappled with was refactoring the legacy code. I wanted to rewrite all 3000+ lines of code in the files I worked on, but I decided against it for the following reasons:
* It seemed strange to refactor one portion of the codebase without the intent to refactor the rest. Good code should have a consistent style.
* During the span of time when it could have been a good idea to bring this up, I was still learning how Javascript and React.js worked. In fact, I heavily relied on the codebase to teach me how to structure my code and utilize React.js. It would have been an overly ambitious endeavor on my part to suggest refactoring.
* It would be a risk to refactor the code when I did not have a comprehensive understanding of the tests and codebase.

I was later told that this was a good decision. However, I still had to refactor the code I had written multiple times to keep up with changing requirements. This could be an indicator that the quality of my code needs work and I would not be surprised if my code was eventually refactored or scrapped.
* **Write documentation.** Towards the end of my internship, it was clear I wasn't going to accomplish all of my assigned tasks and self-assigned design fixes. Things I did well were document any known bugs and the rest of the undone tasks in my assigned issues and specifiy what I had accomplished in my last pull request.
* **Work on the quality of my commits.** I definitely struggled with making incremental commits. A good portion of my commits were made after I accomplished multiple tasks and subsequently, were huge. Glancing through the commits of my coworkers made me realize I could work on the frequency of my commits and the quality of my commit messages. I definitely have to [work](https://chris.beams.io/posts/git-commit/) on this weakness.

### Good advice comes from everywhere.
**Context:** In my mid-internship presentation, I mentioned learning about who I could rely on to answer specific questions I had. While this is a good thing, I realized that following this rule to a tee actually constrained my project progress and personal growth because I would *only* rely on my immediate teammates for answers. As I got to know my coworkers better, I greatly benefitted from reaching out to multiple sources for technical knowledge and career advice.

**Takeaways**
* **Look for mentors.** Definitely common advice, but I listed it anyways because it's a worthwhile endeavor. Through my mentors, I not only recieved technical help, but also advice on how to develop my career, navigate the workplace, and advocate for opportunities where I could learn.
* **Talk to everyone about their work.** Companies operate in different ways. In fact, talking to other interns at a company-wide event, even different workplaces under the same company will function differently. An important aspect of an internship is gaining experience so you can evaluate what makes a job personally fulfilling and what you value in a workplace. Looking back on this summer, I learned a lot about what practices my company and workplace valued and what I personally valued in return. I have to thank a good portion of my coworkers for providing insight on how my particular workplace functioned to reach these conclusions.