Lessons Learned

I’m in the final four weeks of my internship, so a post about what I’ve learned this summer is probably long overdue. Last week was a rather turbulent week for me, so I figured it would be worth compiling a list of my key takeaways from the incident.

Here’s some context. My project is to implement a new feature for the Android app. Another intern has been working on the same feature for the iOS app; however, because the iOS team started implementing the feature long before the Android team started its own implementation, the iOS feature is much closer to completion than the Android counterpart.

It was always clear to me how far ahead the iOS team was with the feature, but I didn’t realize until last week that the way the Android team had originally intended to implement the new feature was completely unreasonable—it would have required rewriting large chunks of the app, which was definitely not happening anytime soon. As soon as my teammate and I came to this realization, we had a sync up meeting with the product manager and designers to redefine the scope of the project. We ultimately decided on reusing much more legacy code, which greatly reduced the scope of my project.

To be completely honest, when we first decided to re-scope my project, I was really disappointed. I was disappointed that some of my code would be completely scrapped. I was disappointed that we wouldn’t be implementing some of the cooler designs according to the original plan. But most of all, I was disappointed in myself. As the intern assigned to complete this project, I blamed myself for not keeping my manager better up-to-date on the progress of the project. I blamed myself for not pointing out how behind schedule we were according to the roadmap. I blamed myself for not realizing sooner that the game plan I was given was doomed to fail.

When I told my manager how I felt during our 1:1 meeting, he told me not to blame myself. While I do understand that I am not completely to blame, I can’t help but think of what I wish I had done differently. Here’s the list:

  • Make milestones as fine-grained as needed. Sometimes that means making your own milestones, too. I was given three large milestones for my project, but what I didn’t realize I needed was smaller subtasks for each of those milestones. My strategy has always been to do as much work as I can each day. It’s worked great for me in the past, but unfortunately, for this particular project, that strategy failed me. It made me blind to the fact that I was way off track and prevented me from evaluating my progress accurately.
  • Make it a priority to know who is involved with your project and in what capacity. One of the biggest problems I faced was not knowing who to voice my concerns to. Early on, my gut was telling me that I wasn’t working as effectively as I could be, but I wasn’t sure who to go to for help. If only I had established a point-of-contact for big picture questions, maybe things would have gone down differently.
  • Write a design doc. Last summer, I wrote a design doc for my feature but didn’t really think much of it. I thought it was just something everyone had to do as part of the process. Now that I look back, however, writing that design doc was a crucial planning tool that probably saved me a lot of trouble down the line. Even though no one explicitly told me to write a design doc for my feature this summer, I would have benefited greatly from doing so, even if only informally. My teammates could have given me feedback on the game plan and perhaps even foreseen the roadblock earlier.
  • Don’t be afraid to question the game plan, and certainly don’t assume that what you are given is correct. My most harmful assumption was assuming that because it was an intern project, someone else must have done a thorough job scoping out the specifications and creating the game plan. Full-time employees are not always given perfectly scoped projects, so it doesn’t make sense to assume that my project would be perfectly scoped either. As an intern, I had the additional handicap of being unfamiliar with the codebase. There’s no penalty for questioning the feasibility of certain approaches, and I should, by all means, question the validity of decisions being made. In the end, we’re trying to build the best product possible, which requires thinking critically and being able to back up our decisions.

People usually think of software engineering internships as opportunities to learn new technologies and to discover what it means to write production-worthy code. That’s certainly what I expected to get out of this summer, and it’s true that I did gain some exposure to writing Android apps—though in a distinctly Square manner. However, it’s going to be a long time before I forget how disappointed and frustrated I felt when my project was re-scoped so late into the game. Moving forward into the future, I’ll be sure to keep the lessons above in mind so that I never find myself in the same situation again.

Advertisements