Internships are tricky. You never know what you are truly getting into. I had prepared all year to land an internship and with all my hard work I landed the perfect opportunity at Xerris. Not only did I improve my skills as a developer, but I ventured into previously unexplored territory in technology. I learned about what a solution architect does, the critical thinking skills it takes to become a machine learning engineer, and as a project manager what a SCRUM Master does. Before I get started talking about the main content of this blog post I want to give a big thank you to everybody at Xerris for welcoming two high school interns with open arms, especially the amazing team of people who made this internship possible.

A bit about myself. My name is Harsh Patel and I just graduated from Dr. E.P. Scarlett High School. I will be starting my Computer Engineering degree at the University of Waterloo this fall! Coming into this internship I didn’t have all of the required skills, actually, I probably had less than 50% of the specific skills listed on the job posting. That often frightens a lot of people. They may feel as if they are not qualified because they don’t have the exact requirements shown on a posting. I think that’s completely the wrong way to think about it. Remember this is an internship, it is meant to be a place where you learn. I specifically applied to Xerris because out of all of the available jobs at the time this is the one that I felt I was least “qualified” for. It's the only way I was going to learn the amount I did over the last 2 months. To demonstrate just how much I learned I am going to run through a project I built a while back but reimplemented with the techniques and steps I learned during the internship.

I mentioned before that I did not have most of the specific requirements I worked on at the internship. To expand on that a little bit, most of my technical experience came from Arduino projects (one of which I will run through), and all of my basic web development experience was from an online course.

Basketball Mini Hoop Shot Counter

The premise of this project was to create a system that counted the makes and misses of the shots I took on my basketball mini hoop. It seems like a pretty simple idea but it gets complicated.

Complications during a project are exactly why roles like a SCRUM Master & Project owner are needed. As a quick overview, SCRUM falls under agile methodology. Agile is a style of management that is focused on delivering the highest value features first. Every 2 weeks a “sprint” takes place where everybody works on specific stories (small tasks) that are later combined into the final project. Software called Jira is typically used in the workplace to create and organize these stories. A Product Owner would figure out what the end product would look like. So when building this project I would become the Product Owner and create a list of functions I want the system to be able to perform. So for this project I wanted sensors to count my makes and misses, I wanted a screen to display these numbers plus a percentage, I also wanted a reset button to reset the numbers, and finally, an on and off switch. I would then take these functions and split them up into smaller story points/tasks to be taken on one at a time. The Scrum Master would decide at what pace work could get done depending on the abilities of the team or in this case the pace at which I can complete work. So if I were to set up this project like a sprint I would decide how many stories I can complete within that sprint and make sure progress is moving along as planned.

Source

Next up, before I can start coding and putting the system together, I need to decide what sensors and parts I am going to buy to make the system work. This is similar to what a solution architect does. In the software development world, a solution architect at Xerris would select what AWS services to use during a project and overlook the integration between each service and how it would work with the project. In simpler terms, it’s a high-level overview of the project parts. In my project that would translate to picking the appropriate Arduino board and corresponding parts such as sensors, a screen, buttons, and jumper cables. During my internship, I put together architecture diagrams for a Netflix-like service with different AWS and general services to make it work. Similarly, I have shown below what that would look like for my project. A diagram containing all of the parts in a high-level overview of what the project would truly look like.

Now we get to the development stage. My development at Xerris involved TypeScript and some HTML / CSS. The script for this system was written in C++. However, there are still many similar aspects of the code that still link these scripts.

The first one I am going to talk about is coding standards. I learned about these coding standards at Xerris during my first practicum in Web development. In the Web development world, this document is the industry standard rules for coding. In the personal project world, there are no rules! That being said, there are still some basic rules you should always follow for your sanity.

  1. Comment! Comment! Comment!

Although this rule may not be applicable when you are pushing code into production for a client, during development and personal projects I strongly recommend commenting on your code. It helps keep track of your thoughts and helps others who read the code understand what is happening at each function. If you look at the script for my project code, I have commented as much as I could to refer back to whenever I need to read the code. Even though my comments aren’t the best, I could add more detail, but some comments are better than no comments, especially as a starting point.

2.  Indenting

This one is strange. If you don’t indent properly the computer doesn’t care, your script will run normally (unless it’s python). This goes for comments as well, why write comments if the machine will just ignore them. Why put in all that extra work? As Harold Abelson said, “Programs must be written for people to read, and only incidentally for machines to read”. We don’t write code for machines, they just happened to understand it. We use coding languages to communicate the machine-executable code with other human beings for collaboration. It’s the essence of why coding languages exist or else everybody would be writing 1s and 0s that only computers can understand. Back to the point, please indent your code properly so others can understand what you wrote when going back to review your scripts.

3.  Variables on top

The final rule I want to mention is to have your variables at the top of your script whenever possible. It helps with two things: first, readability of code becomes easier because functions won’t be cluttered with variables, and two, it keeps all of the variables organized at the top to make it easier to reference too. Once again if you refer back to my script I have placed all the declarations at the top whenever I could.There are a lot more coding standards that you should follow which is why I highly recommend going through the industry standards to get yourself into proper practices right away.

Moving onto the second thing I wanted to talk about. Software testing.

Testing is very important, it ensures that you avoid bugs when putting code together and it also ensures that the script runs as intended. We did some basic testing during our development practicum and it was a completely new concept. You write small blocks of code and write “tests” for that code to make sure it runs properly.

This is a basic testing script that checks if the numbers in any given array are in order. If you are interested in learning more about testing I recommend getting started here. For my project, I tested some of the sensors individually to make sure they functioned as I wanted. So similar to Jest Testing I created individual scripts of each of the sensors I ran through the scripts before integrating the components. Here is where you can find some of the individual test codes. To reiterate, testing can save you from hours of integration bugs. Just create tests at the start so you don’t have to worry about it later.In summary, these 3 roles of project management, solution architect, and developer come together in harmony to create a project. That is the basics of how a production-level project is taken care of or even a personal at-home project like mine. During my two months at Xerris, I learned about all of these roles in detail plus machine learning and many other aspects of working in a collaborative, team environment. If you are interested in what the actual project finished looked like here is a Video Demonstration.

Before I finish this blog post I want to encourage any student who is interested in working in this field to apply to Xerris. On the very first day, we met our amazing mentors for each practicum as well as the team that put together this program. Over the past two months, I learned real-world applicable skills. Gaining internship experience early on in the industry will make you an outstanding candidate for any software-related role at any company, maybe even at Xerris as a full-time employee! The amount I learned each day at this internship was amazing and at first, I was definitely overwhelmed but the team was always there for me. They supported me if I had any questions and as a company, we would meet up weekly just to chat or play games. It truly is an amazing place to work and a great starting point for my young career. I leave this internship more curious than I started and more excited about what lies ahead.

Harsh Patel