An incident that caused me to question a previously held assumption

I have always thought that a good software engineer is determined by how well I can think of brand-new solutions and write new code. During my Software design and implementation course, I realized that developing software required more than just writing new code; but it encompassed working in a team, writing clean code, proper encapsulation, and above all, proper presentation of the software product developed.
Little did I know that these were not all that made a great software engineer, especially in a large organization like Microsoft. During the last three weeks, I did not write any new code. I spent most of my time at work reading portions of the Microsoft Excel codebase that related to a task assigned to me, debugging that code to understand how it works fully, then copying and pasting that code before customizing it to achieve the new task. I have never thought this is anything close to what a software engineer does. “Is that plagiarism? Can we even call this our code?” I asked one of my teammates. On sharing my shock about re-using code, my mentor told me how it is common for software engineers to re-use code written by someone else. My mentor explained how with a codebase as large as Microsoft Excel, it is rare that someone has not implemented something similar to what you are working on, especially in an internship project. Furthermore, he explained how a successful intern experience depends on writing code that fully integrates with existing Excel code without differentiating intern code and full-time employee code.
This conversation with my teammates and our mentor caused me to question why leveraging the work of others is not encouraged in school if it is such a crucial skill in the industry.

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