When Cory and I decided the make the transition from our previous career fields to development, one of largest deciding factors in picking a code school was career services and job preparation. We both chose Epicodus because it offered an internship as part of the schooling process, which is how we were both placed at Olio Apps.

My hopes and expectations for this internship were to gain more confidence in my work and to be able to develop better technical skills. For Cory, he wanted to learn how to write cleaner code and to be a more effective problem solver.

The time we spent at Olio has been an insightful and enlightening experience that has helped to codify the materials we learned in school. Here’s a overview of what we’ve worked on the past 5 weeks.

Week 1: Bootstrapping our JavaScript

During the first week of the internship, Cory and I were asked to complete a set of practice exercises to make sure we were up to speed on the fundamentals of JavaScript and in-house styles before releasing us into a project code base. This included brushing up on ES6 notation, .map(), .filter() and .reduce(), destructuring objects, using the spread operator, and using a different text editor, VisualStudio Code.

Ami: How did you feel about that first week?

Cory: It was anxiety-provoking, but only because I didn't know what to expect because it was my first position as a developer. I think it was helpful to have a cushion before being let into a code base.

Ami: Yeah, I think I had a similar experience. I think we had good mentorship, not only from Aron but also from other people on the team that were invested in seeing us work hard and do well. It was like the "good" kind of anxiety, as far as being productive goes, but definitely a bit nerve-wracking for sure.

Cory: One thing I thought was helpful was that Aron led us through the prep period and pushed us to learn fundamental JS concepts. He was adamant about having us explain them accurately and asked us to do that verbally, which was an effective way of internalizing concepts and improving our technical communication skills.

Week 2: Local APIs and TypeScript

During the second week, we were asked to brush up on TypeScript and were presented with a practice problem involving creating a local database and API, creating methods to modify it, and then creating a short presentation on how it worked.

Cory: What were your thoughts about that week?

Ami: It was difficult, but again, it was nice to have a sandbox environment to learn in. On top of that, we never really covered local databases or Node at school, so it definitely pushed me outside of my comfort zone.

Cory: I think that week I really learned to ask clarifying questions ahead of time. It was really easy to go down the rabbit hole of not solving the problem they asked us to solve. Taking the time to get clarification up front really saved us a lot of trouble later on.

Ami: Yeah as far as soft skills go, that was definitely one I think we both improved that week that I think we’re doing a good job of integrating into our current workflow.

Week 3: Unit testing, test matrix, and test-driven development review

During week 3, we moved out of the sandbox and into a real code base, writing unit tests for a late-stage application that needed to be finished and shipped out within the next few weeks. Cory and I also had the chance to review a blog post draft by our co-worker Frank about project architecture and Redux-Saga utility functions and how they worked prior to writing tests for them. We also ran the manual tests on the Android tablet with the software installed on it and recorded any bugs or discrepancies in a test matrix.

Cory: That was a great refresher for unit testing, because I think we only did one week of unit testing at school. It was also the first time we'd used Jest for unit testing, as opposed to Jasmine. What did you get from that?

Ami: What I got out of this experience was the ability to jump into an unfamiliar codebase, and learning to read other people's code to create the context you need in order to contribute effectively.

Cory: Yeah, at Epicodus, most of the code that you're looking at or collaborating on is your own, so it's very insular. And most of what we were doing when we jumped into that codebase was reading and not writing anything.

Ami: And it was definitely validating to realize that while the code is developed by more experienced engineers than ourselves, it's not ironclad. We ended up finding actual mistakes and bugs through writing unit tests, and on that front, we genuinely contributed to the project.

Week 4: Feature creation and PRs

Week 4 we moved on to writing features. This was one of the first times we'd seen a software feature from the beginning of the development cycle to the end. This was also the first week that we did any real PRs, for which our mentor Aron wrote a robust checklist. Cory and I also sat down with Scott and Aron to talk about the growth mindset, good developer habits, expectations for PRs, and how to communicate effectively.

Cory: What did you get out of this week?

Ami: We definitely got to practice more problem-solving since we were the primary authors some of those features.

Cory: It was also helpful to learn Redux-Saga through the codebase. It was the first time we developed a feature for Saga, so that reinforced everything we'd learned prior to that.

Ami: I think the PR checklist was helpful. It falls in line with having good communication skills, making sure that you can document what you're doing, and explain in plain English and diagrams what your PR does.

Week 5: Debriefing and transitioning into the workplace

This week, we wrapped up the late-stage application we worked on in Week 3, and started working on new features on an early-stage application. We also talked about creating more internal documents for new interns and on-boarding, better broadcasting, and an in-house style guide.

Cory: What I got out of this, from Aron, was that you should always be transparent about where you are in the process so there's no downtime if you're finished with a project or feature.

Ami: I think we also learned about the anatomy of a PR, what's good and helpful to add and what isn't, and just the workflow for writing an application from scratch.

Cory: We also learned to navigate the difference between pull requests on GitHub vs. pull requests on BitBucket.

Conclusion:

Ami: So what did you get out of the whole experience?

Cory: I feel more confident about approaching writing code with best practices and being more comfortable with what I don't know. And how the point of going from "not knowing anything" to "knowing something" is just embracing the growth mindset process - just because you're unfamiliar with something doesn't mean it's a bad thing, it's just something you need to learn.

Ami: Definitely. I feel like my code writing has improved and I feel good about that, but I've also learned how to communicate more effectively and like you said, being more comfortable with making mistakes and not knowing everything.

Cory: Yeah, it's common sense, but it's nice to be in an environment where it's okay to make mistakes as long as you learn and improve from them.

Summary

In summary, we learned how to be better coders and better communicators. Part of that process was learning how to be humble and focus on improvement rather than shortcomings. We're both incredibly grateful to Aron and Scott for giving us the opportunity to be here, as well as the rest of the staff for being welcoming and supportive mentors. We hope that in the future we are able to pay it forward to future interns and help to create a growth-focused community of junior developers.