My Experience as Loopio’s First-Ever Intern
I would like to preface this blog post by saying how ridiculously grateful I am for the opportunity I was given to work as a sixteen-month intern at Loopio. The experience was full of learning, growth, and lots of smiles. But before I dive into my Loopio story, let me introduce myself…
A Little Bit About Myself!
My name is Lucas Gismondi, and I am currently studying computer science at the University of Toronto (U of T). A few things I enjoy doing outside of work are playing table tennis, baseball, and chess. Going into Loopio, I had experience with Java, C, and Python, gained mainly from school projects. One of my favourite projects was building a natural language processor that could predict where someone was on the political spectrum based on their Reddit posts!
Why I Chose Loopio
I had stumbled across Loopio at a recruitment breakfast at U of T where I met Matt York, one of Loopio’s co-founders and its chief technology officer (CTO). When I arrived at the office for my technical interview, I was struck by a wave of energy as I walked through the door. Within seconds, it was clear that Loopio had built a welcoming and supportive environment.
When waiting for my interview, I observed lots of communication, passion, and a general sense of happiness in everyone. The opportunity to learn new technologies, gain insight into different areas of the business and have the autonomy to drive forward initiatives that I cared about made the decision a no-brainer.
My Expectations Going In…
I began my Loopio journey on May 1st of 2018 as a full stack junior software developer. Starting my internship, I had very little experience with web technologies. Previously, I had been building smaller projects purely on the client-side. Learning to connect a frontend with a backend was something completely new to me.
Being Loopio’s first intern with no previous industry experience, it’s safe to say that, to some degree, it was going to be an interesting experience for both parties. I expected to meet new people, learn new technologies, take part in building out features, and have fun while doing it! But to be honest, the idea of all this was so abstract considering I had nothing to refer to. I didn’t fully understand what I was getting myself into, and I didn’t realize that I was about to enter the best sixteen months of my life.
A Day In My Life At Loopio
9 AM
- Get into the office
- Fill up my water bottle
- Write down my personal goals for the day. I found this to help substantially with my success. It allowed me to track my progress throughout the day and ensure that I was hitting measurable goals on a regular basis.
9:30 AM
- Attend my team’s stand-up. Here we would discuss our team’s sprint goals, blockers, and overall progress to ensure we were on the right track.
10:00 AM
- Start to code! This could include starting to investigate a recent bug, continuing on the work from the day before, or reviewing pull requests.
12:00 PM
- Break for lunch and get dumplings from Juicy Dumplings! (Most of the time 😃) Definitely my go-to lunch spot in Chinatown (which is where our office is located in Toronto). Delicious and affordable.
1:00 PM
- Time to get into “the zone.” The afternoon is when I personally work the best. I have a solid chunk of time to sit down and get some really productive hours of programming in. Some afternoons would also include customer calls or other meetings pertaining to the features I was working on.
4:30 PM
- Join the team to Get Loopi! On Fridays, Loopio would have two Loopers host a party with a theme. We would come together to have food, drinks, and share some laughs. It was a great way to let loose and end the week on a good note!
Loopio’s Focus on Growth Culture
Loopio’s growth culture is amazing. From company events like “Discovery Week” to Lunch & Learns, there was never a shortage of opportunities to expand your knowledge and grow as both a developer and a person.
“Discovery Week” was one of my favourite parts of the year. Each employee was given the opportunity to dive into a department other than their own. We would be presented with processes, techniques, and tools they used. This gave us a better understanding of that department, but more importantly how they affected and contributed to the business.
Loopio also hosts its own internal hackathons. They are a great way to help innovate the product, test your skills, work with new people from other departments, and potentially see your ideas make it to the roadmap. It was amazing to see the amount of progress our team was able to make in just a few days!
In terms of company growth, Loopio’s headcount doubled from ~60 to over 120 Loopers, we moved from a one-floor to a three-floor office, and my team grew from four to twelve people all during my time at the company! I may not have had any experience at a company before Loopio, but I have a good feeling that this kind of growth isn’t normal. I’m so happy to have seen it all first hand.
However, having lots of new faces and bigger teams comes with some challenges…
The Biggest Challenge
As the feature teams became bigger, we had the capacity to take on multiple projects in parallel. This meant we needed better prioritization, more time to plan, and most importantly, more communication.
At the department level, we found that silos formed between the teams, which eventually led to a lack of communication between them. Although silos allow teams to truly master the features they are in charge of, there is a high probability that they will be touching code tied to another team when implementing new features. This can make the platform more vulnerable to bugs in areas not owned by that team.
At the team level, silos were less prevalent but were still there to a degree. The same communication gaps were similar to those at the department level.
The team was quick to come up with some solutions to close the communication gaps. Here is a couple:
Hold feature sync meetings
- Depending on the feature, it may be useful to explain the challenges and learnings you came across when implementing that feature. It allows for more technically directed questions and a deeper understanding of the architecture for that feature. These feature syncs are held in the hopes that others can learn from the mistakes, how the feature may affect the work they are doing, and possibly pick up some new techniques.
More paired programming across and within teams
- Paired programming can feel slow at first, but this is only in the short term. In the long term, everyone is on the same page and has the full context of the problem. Having the ability to quickly bounce around ideas/questions may expose things much faster compared to working solo.
There will always be communication gaps, but it’s up to each developer to exercise these muscles and mitigate the gaps.
My Biggest Takeaways
Throughout my time at Loopio, I was constantly learning best practices and new ways to produce better code. Here are my top four takeaways from the experience:
Focus on the scope of the problem at hand
Some tasks require you to modify multiple areas of the codebase. At the beginning, I would want to refactor everything that I thought should be refactored and make it part of the task I was already doing. This is definitely not the right approach because you risk introducing more bugs, having to refactor significantly more than what you originally thought and having a large pull request that can use up a ton of your code reviewers’ time! A better approach is to take note of what you would like to refactor and mark it as tech debt. There is normally a process for handling tech debt tasks, and it will be prioritized for your team to tackle at another time.
Focus on architecture vs code syntax in pull requests
This is something that is very difficult to master. In an ideal world, catching syntax and styling is automated as much as possible, but realistically this isn’t always the case.
Focusing on questioning the architecture and how the code is connected can expose potential issues and improve your understanding of the problem. Of course, there are cases where commenting on styling/syntax can help with the readability of the code, but nitpicking will not improve the functionality of the code.
Write readable code and not comments
Working on my first few tasks at Loopio, I didn’t notice too many comments within the codebase. I had noted to my manager that this was the case and I was very quickly taught that comments in practice work against you. Not only do you have to maintain the code, but now you potentially have to change the comments tied to that piece of code.
In the long term, comments will become out of sync with the code and will eventually be misleading and provide nothing but noise for developers. Instead, you should write clear and readable code such that the code naturally describes what it is trying to do!
Don’t abstract too early
This mainly relates to the experience I gained with React components, but it can also be applied to other frameworks/languages.
When writing new smaller components, most of the time they can be abstracted to be used in multiple areas of the codebase. However, if you only need that common component in one instance, you may be abstracting without enough information as to how it may be used in multiple other instances.
That may not always be the case, but a great approach is to build what you need without abstracting and until you see the same opportunity to abstract in a few more areas, only then should you make the abstraction. Abstracting too early can create much more refactoring work than needed in the long term for the places using the common component.
Summing It All Up…
My experience at Loopio ended up being so much more than I expected. I made meaningful relationships across the company, gained a strong understanding of the React, Redux and CSS frameworks, PHP, MySQL, automated testing, and SCRUM practice. I was able to take part in customer calls and listen to some of the amazing feedback and struggles they had with features I had worked on. I was given the opportunity to present to the company what our team had accomplished at the end of a sprint on multiple occasions. But the one thing that hit home for me was seeing first hand how important the features I had a hand in were to the business.
Loopio hosted its first customer conference in May of 2019, where our Chrome Extension was demoed on stage, for the first time, in front of ~150 customers. Hearing cheers across the conference room after the demo filled me with nothing but joy and happiness. Our team had put an enormous amount of work and care into this feature and it was amazing to see the project all the way through!
To put the icing on the cake, I had the privilege of witnessing and learning from three amazing co-founders! I can’t go without mentioning how great it was to hear about where they started and then seeing them on stage showcasing Loopio to users who are excited about the product. These three are people I look up to and am excited to see how far Loopio can take the product!
Acknowledgments
Thank you to Team Llama for being incredibly supportive. It was amazing to see each and every one of us grow into a team that could tackle any problem that came our way. I will miss our hunger to learn and improve, our ability to be candid with each other, but most importantly, I will remember our laughs, good times, and successes.
Thank you to the entire Engineering Product & Design team for teaching me more than I could have ever imagined. All of you welcomed me to the team with open arms and treated me like a full-time employee. I will miss all of you.
And of course, thank you to Loopio for giving me this wonderful opportunity, and letting me be a small part of your story. Loopio has changed my life in the best possible way and I couldn’t be more thankful. I’m excited to see the company Loop it to the moon and beyond!
Although I am turning the page on this chapter, I am placing a large bookmark on this part of my story as this will mark the backbone of my career. Loopio has opened my eyes to a whole world of possibilities and this is just the beginning.
P.S. There is so much more that I would like to have covered here, so if you have any questions about the experience please don’t hesitate to contact me!
https://www.linkedin.com/in/lucasgismondi/
Lucas Gismondi
