My steps to understanding task requirements


I got a new project task this week after completing my first project task. The new task adds a feature to our current project that my internship manager considers a core part of the project. I have been working on the task for one week, and it has taken me so many work hours researching how the different parts of the methods work together and how I can use them for the task. When I was first assigned this task, I asked my manager for possible Engineers on my team who worked on a similar task. I aimed to know the potential Engineers to contact if I had any questions. Fortunately, my manager mentioned himself as the main point of contact since he had worked on a similar project.
After spending a day browsing around the Excel codebase, I requested a meeting with my manager to explain the task expectations and recommendations of places I should look over. This meeting was helpful because I gained clarity on the task expectations and saved so much time by starting my research with the different places that my manager mentioned and expanding to other places I deem necessary for the project.
Throughout the week, I contacted my manager seeking clarity on some parts of the project that I was not fully understanding, requesting feedback on my approach to different parts of the task, and discussing the blockers I am facing. Communicating with my manager frequently about my progress has provided insights on better approaches and edge cases to consider as I write the code for my task. Although I have a better understanding of the task and made significant progress toward thoroughly implementing it, I lost one day researching something I knew very little about before reaching out to my manager. I wish I reached out earlier and not lost an entire workday in irrelevant research.

Comments

Post a Comment

Popular posts from this blog

Software test engineering career

During the last two weeks, I talked to a couple of full-time employees to learn how Microsoft tests its software and a career option as a Software Test Engineer. Test engineers write software tests like unit tests, sub-system tests, scenario tests, and vendor tests. Unit tests are tests written to check how different functions or methods work at the lowest level of abstraction. During a conversation with a former Test engineer, I learned about Test-driven development, where test suites are developed before the actual development of the product. Although test-driven development is highly encouraged, some engineers write tests to verify their product's functionality after the coding. One importance of Test-driven development is fully understanding various edge cases to consider while developing. Sub-system tests are tests written to cover code shared between different components. A specific type of sub-system testing called cross-platform testing verifies how code behaves on other E...
Read more

Learning source Depot

 I remember asking my manager about the technology used in Microsft Excel projects and what skills would support me during my internship experience. I was glad to know that the primary programming language we would use was C++; however, I was surprised that we would use a new version system called source depot, which is different from Git. Source Depot was a completely different source control that I needed to read about before my internship. My primary goals were to learn how to commit, push, pull, and merge changes and the similarities and differences between Git and Source Depot that I can leverage when researching Source depot.  Unlike Git, a distributed system with local and remote repositories, source depot is a centralized version control system with a central repository and client mappings to that repository. Another significant difference is how Git has terminal and graphical user interfaces(GUI) options, but Source depot is accessed through the Command-line option. W...
Read more

Lesson from overcoming a challenge

 I spent most of the week reviewing comments on my code review and preparing for demo presentations of the end-to-end customer experience of our feature. During my last demo presentation, I remembered how overwhelmed I felt during my first week at the internship. Everything from understanding my project description, adjusting to work in Pacific Standard time when physically located in Berea, and trying to understand the meaning of the C++ code in Excel's codebase seemed a lot to understand. By taking one task at a time and reaching out to my mentors and manager whenever I needed help to understand something, I overcame my technical and non-technical challenges. One major challenge I faced during my internship was executing my second project task. My task was to enable customers to navigate to a specific sheet and cell in Microsoft Excel using deep linking. To deep-link to the customer's cell location, I worked with code from the front and back end of SharePoint's server, wh...
Read more