Starting a new internship can be intimidating; new responsibilities, new people, new office, and perhaps the most daunting of all, a new codebase. With so many new things, it’s easy to become overwhelmed and want to dive straight into the code. I’ve had the opportunity to be in five software internships over the past few years through the Portland Cooperative Education Program (PCEP) and as a result, have learned enough to compile a list of things to do at the start of an internship. I hope the following things help you start off on the right foot:
1. Complete Onboarding
When it comes to onboarding, every company does it differently. If you are a part-time intern like I was most of the time, this is a good time to establish the hours you’re going to be working with your team. Make sure to give yourself time to get from school to the office and vice versa. More importantly, make sure you’re not too overloaded to do your schoolwork.
2. Introduce Yourself
I didn’t learn the importance of making a proper introduction to my coworkers right away. I’d spend hours on end banging my head against a wall (metaphorically) because I didn’t want to ask for help from someone I didn’t know. If I had introduced myself and gotten to know them earlier, I would’ve felt a lot more comfortable asking for help. Feel free to invite people for coffee or lunch and take every opportunity you can to go with someone who invites you. You’re being hired on as an intern to work with your team, not to be a lone wolf who tries to solve all their own problems.
3. Settle into Your Environment
I had an internship where I did didn’t get my computer until two weeks in and had to read out of a textbook. Hopefully this is a rare experience, but if you don’t have what you need don’t be shy about asking for it and following up with IT.
In my experience, setting up my dev environment has been tedious. Most companies do not have a well documented process, so this is where some assistance from a co-worker will be really helpful. Asking them for help shouldn’t be a problem now because you’ve already introduced yourself. Now is a good time to download any programs you use for productivity and configure your IDE to adhere to the code style of the team.
4. Get the Lay of the Land
Once you’re all set up, you can actually start learning. If you don’t already know about git (or any other Version Control Software), I highly recommend you to learn it. It’s absolutely crucial to figure out how VCS is used before diving into the code.
You should also get familiar with the programming language(s) that the application is using and the parts of code that your team works with. Watching a few videos and then doing an online tutorial or two helps me get comfortable with the code. Once you’ve got a better grasp on the language, you should take a look at the structure of the code for the application. Some things to look out for are:
- The folder structure for the project, including
- Back-end/Server-side code
- Front-end code and styles
- Test code
- API code
- Database code
- Which libraries/modules are used
- These can typically be found in files that deal with dependencies such as pom.xml, package.json, Gemfile, etc)
5. Experiment
Look through the application, think of something you’d like to change, and then make the necessary code changes. Figure out how to write tests for your code and look at existing tests as reference. Try to make changes related to each area listed above if your team works in those areas.
Another thing that’s proven to be extremely helpful for me is picking up a small and easy task and go through it with another engineer who has been around for a while. At Jama, we use a technique called pair-programming to get the perfect balance between productivity and sharing domain knowledge. If you’d like to learn more about pair-programming, check out my colleague’s blog post about it.
6. Contribute!
After you’ve gotten comfortable with the code and making changes, you should be ready to start fixing small bugs and adding new features. To get your features and fixes live, you’ll need to know the process for putting your code into production. This process typically involves some form of merge request to get your code into the master branch. The merge requests are a an excellent way to review your code changes and have another developer look over it to ensure that it’s high quality.
Above all, remember that the main point of an internship is to learn new things. Don’t worry about contributing a lot until you’re comfortable with making changes on your own. Don’t be afraid to make mistakes; your VCS is very forgiving and your team will be too.
