How my perception of software engineering roles has changes since the start of my internship

 At the start of my internship, I was disappointed in myself that I had not written any code for the project. I was overwhelmed by my project requirements and how no one on my immediate team had ever worked on adding our team’s feature to a mobile client. This meant that I would be the first engineer to add this feature to a mobile client. Additionally, it meant that my approach in adding the feature to Teams mobile would provide a template to extending the feature to other mobile clients like Outlook. My first step to approaching the project was talking to different teams that were working on project components similar to mine. These meetings provided insight on the entry point of my project and resources. An important resource was one abandoned pull requests of code that an engineer had written in a Microsoft hackathon attempting to implement my feature. After gathering substantial information, I embarked on preparing an engineering design document that would help my immediate team offer feedback on my project.

Although the process of understanding the project requirements and gathering the resources I need for my project was not accounted for in my project plan, I have found it the most important to my progress with the project. This has changed my initial perception that a software engineering role is all about writing code; a perception that had caused frustration at the start of my internship. I have accepted that I contribute better to a project after gathering information and understanding how different parts of the codebase work together. Beyond my internship, I plan to always allocate planning time to all projects before I start implementing any technical parts.