My Time as an Intern on the Engineering Tools Team
Entering InVision, I had programming experience from computer science classes throughout high school, but I didn’t have a good sense for how software is actually built by teams in the real world. My time at InVision allowed me to gain experience developing with new technologies while getting exposure to the practices and methodologies used in the industry.
I’m based in Portland, Oregon, so on my first day I actually went into a physical InVision office downtown. Although I knew InVision had employees all over the world, I had the impression I would be entering a bustling office space. I was surprised to find the office sparsely populated. For a first day though, this was actually kind of nice. I only had to introduce myself to a small handful of people, and I got to enjoy a quiet view of the city as I set up a flurry of InVision related accounts. By the end of the afternoon, I was kneeling before my password manager.
Given the freedoms of working remotely, it makes sense that few people use the office. To me there seemed little reason to commute when your teammates are located elsewhere anyway. As such, I spent most of my internship working from home, and I became more familiar with how a remote company works. All meetings happen online (no surprise there), but what struck me was that even if multiple people are in the office, they are required to move to separate rooms before joining the call so no one has an unfair advantage in communication.
Despite this remote structure, I was really impressed with how well InVision maintains a company culture even when all interactions happen through a screen. Everyone is very positive and friendly towards one another and emojis abound throughout the Slack channels. At first I was nervous to ping strangers for help, thinking people with real, important jobs wouldn’t want to be bothered by the needs of a lowly intern. However, everyone I reached out to was more than willing to loan me their time.
Though I spent most of my time working remotely, I did choose to go into the office about once a week, and I gained an appreciation for having an independent environment for work. At school, my productivity and leisure both occur mainly in the dorm, and I spend an evening in the library when I need a change of pace. Going to InVision’s physical office was similarly useful and helped me occupy two distinct headspaces. Plus, the air conditioning was a real savior during some of the hottest days in Portland’s history.
Weekly trips to the office also enabled me to meet face to face with my manager, Sejal. She walked me through Agile development practices and broke down the differences between Kanban and Scrum methods. Since my project’s development was independent from the workflows of the other people on my team, I wasn’t expecting this kind of training. However, it was a welcome learning opportunity seeing as it seems to be used wherever software is made, and it was really helpful in contextualizing the daily rituals of team meetings.
As for my project, I was tasked with building a video concatenator bot for Slack. Engineering teams regularly release video demos of what they have been working on, and when they start to pile up it can be cumbersome for a viewer to click through them one by one. So, the Video Concatenator puts all the videos uploaded within a week together into one file and posts that to the demo channel. Though simple in concept, I was excited by it because its function was practical and could potentially be useful to everyone within the company.
As I started piecing together sample code for Slack’s API, I became convinced I could have the project completed within two weeks. Alas, it ended up taking several more as I rebuilt many features several times over. I found that implementations that worked at a scale of one didn’t work so well when multiple people were accessing the program through multiple Slack channels. Each time I realized a flaw in my current design and had to backtrack, I felt like I was getting a stern reminder in planning for scale instead of crafting jerry-rigged solutions.
Unlike my CS classes, which were mostly concerned with using data structures to write algorithms, building the Video Concatenator required working with a lot of code from other parties. Much of my time was spent reading documentation and writing test programs as I figured out how to cobble together existing APIs to interface with the services I needed. During development on the project, I learned how to use Heroku, virtual environments, several AWS technologies, SQL databases, and some (very basic) web development. However, I think the most valuable lesson I learned was to always keep the user in mind.
As the sole developer of the tool, I knew its ins and outs, but I needed to put thought into how to best familiarize a user. Features that should have been obvious for usability were initially overlooked, and some information just wasn’t being presented in an approachable way. To improve this, I tested the bot with a myriad of tweaked responses to see what felt best. In the end, I think I might have spent a little too much time picking emojis for the bot.
As I leave InVision and return to the classroom, I’ll remember that although software is built by individuals and teams, it is made for the masses. After working for a company whose entire ethos is good design, I guess it was inevitable that I would come to appreciate it myself.
I’d like to thank Sejal, Jon, and Victor for letting me tag along on the Engineering Tools team for the summer and for supporting me throughout this experience. May your backlog be spacious and your bonusly plentiful.
If you’re an InVisioner curious about the Video Concatenator, you can find it in #engineering-demos on Slack, and you can check out the project here on GitHub.