Internship Post #12

Revisiting Week 8: Tracking your growth

Over a month ago, I had just started on working on the REST services for a schedule editing tool on the software my team is building. I’d say I’ve learned way more in this past month than I have in my first two months of the internship because I was able to interact with my team more and even apply the skills that I learned in the first two months more deeply. By now, I don’t really feel like an intern anymore, I feel like I an actual employee of the company. I never expected to be working on tasks where clients would be directly interacting with so soon and that has definitely changed by perspective on the quality of code that I create. Sometimes, it isn’t good enough to get something to just work, it has to work and make sense to everyone who might be using it in the future, and I believe that is where most of the work is put in.


Over the last week, I had to take a break on working on additional tasks and work on refactoring and making sure my code makes sense to my peers, especially as I get closer to the end of the internship. In the code that I had before the week started, I was violating the Don’t Repeat Yourself principle of software engineering, which basically says not to repeat code. However, this was a problem because the underlying code that my REST service was depending on was designed in a way where not violating DRY would be a challenge. I then had to collaborate with two of my team members to come up with a design that would make sense and be efficient. Eventually, we decided to eliminate redundant endpoints and reduce them to one endpoint, using the filtering to differentiate between the underlying objects. Unfortunately, this took out of week of development of tasks that I needed to complete and am now behind going into my last week of the internship.


Throughout the internship, I grew so much especially in regards to my career in software engineering. I went from an intern working on tasks that seemed simple and easy to do to tasks that required a lot of teamwork because of the potential risks it has when I leave. From this experience I was able to gain so much experience in the way I approach a problem in software engineering, and sometimes it isn’t about getting the problem right. It needs to be solved in a manner that makes sense to everyone so that they may use or change it in the future easily. It slows down progress a little bit, but it gives me more insight on the amount of work that I am capable of doing in a typical 40-hour work week, which could be very helpful knowledge in future interviews about my own strengths and weaknesses.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s