How to Be an Intern

Hi future Toiler,

Welcome to the team! I’m William and I was one of the Toil interns. I know onboarding can be scary, so I put together this short doc with some of the things that I learned / find helpful during my time working on Toil. Congrats and I hope you have a wonderful internship experience!

Some tips

Onboarding

Toil is a large project. There are a lot of components that are difficult to understand at first, so my suggestion is to not try to learn everything at once. I started off reading the documentation but a lot of the concepts only made sense after I started working on tickets. The first few sections of the docs and the architecture page were helpful for me to get started, and the rest were great references when I started working on particular parts of Toil.

(You probably don’t need to read this document all at once either. This contains the things that I learned in my entire internship, so some of them are not relevant during onboarding.)

Explore your interests

You get to choose most of the tickets that you want to do. There are tickets at the front of the backlog with higher priorities and also a list of tickets with the “intern” label that are relatively friendly to Toil beginners, so you can browse through them. You can pick tickets that interest you, and it’d be a great learning experience to pick tickets that involve working with a tool or technology that you are not familiar with. I never thought about learning Docker, AWS (S3, EC2, etc), Kubernetes, etc, but I became familiar with them one by one.

Code editor

I was using PyCharm in the beginning but switched to VS Code. I think Adam is using Vim. You should be able to use any code editor that you like, but just make sure to enable auto complete, linting, etc to help with development. For VS Code, I find it helpful to change the type checking mode to ”strict” so you don’t have to run mypy as often to check for type errors. Also, learn the keyboard shortcuts of your editor to speed up your development!

Pair programming

I only did two quarters of pair programming sessions with Lon and Adam, but I find them to be very helpful. You should be able to set up weekly pair programming meetings with Adam, Lon, or another intern?

Pull requests & code reviews

I think it is recommended to have small pull requests so they are easier to review, but mine tend to be pretty large… It would be great to try to break up your tickets into smaller pieces that can be merged independently, although it is not always possible.

After I create a pull request, I like to go through it myself first to make sure everything looks good. For code reviews, Adam and Lon tend to go through the pull request thoroughly, which has been a great learning opportunity for me. Having a second pair of eyes on your code can help identify a lot of edge cases, logic errors, typos, etc that are not immediately obvious to you. I also find it beneficial to look through other pull requests to see how other people approach a ticket.

Take notes

This is not just for Toil, but I started to keep a dev notebook to document the things that I am learning. There are many things to learn in software engineering, and it is just not possible to know them all. For Toil, it was also helpful for me to jot down what I did, commands to do certain things, errors that happened and how I resolved them, etc.