This summer I had the truly unforgettable experience of working as an application engineering intern at GitHub. I was officially part of team Workflow Party Corgis, an intrepid bunch of four interns and our four senior engineer buddies, along with two engineering managers and our very own trusty designer. Over the course of ten weeks, the Party Corgis collaborated with teams from across the company, including Data Analysis, Design, Documentation, Editorial, Platform, Product, Security, Social Media, and Support. Eventually, we found ourselves with a feature in two parts: a toolbar for inline actions in the code view, and a rendering function for showing previews of code inside issues and pull requests. I’ve been asked to blog a bit about our journey, so, well, here goes!
In the beginning, there were two: Saundra and myself. Originally this project was assigned to only two of us, while the other two interns on the workflow team, Michelle and Bryan, were given another project. Our manager sat us down late during the first week, explained a bit about the background and the overall idea, laid out some checkpoints and milestones, set us up with all the resources we needed, and then basically said, “go!” At first it felt like getting dropped in the deep end, but in a really good way. Like having to sink or swim, but in a pool full of olympic swimmers ready to help the moment we reached out.
By the end of the following week we were expected to have a proposal for the overall architecture, including rough ideas of database migrations, data analytics questions, and any new infrastructure needed in the app itself. With those goals in mind, we got to spelunking; the GitHub application codebase is, as you can imagine, enormous, so it took a bit of clueless exploration at first to get our bearings. In the meantime, Saundra suggested that we both sit down and write out what we wanted to get out of this internship, so that we could have an idea of how we wanted to split up the tasks. It turned out that I wanted to really get to know Javascript, while she was more interested in the new migration that we would need. Meanwhile, I was kinda spooked by the database, and she wasn’t as interested in the frontend. With that, we both could get started on a task we liked, and that was pretty neat.
Then, around that time, we got a surprise! Instead of remaining two separate pairs on separate projects, we learned that we’d be joining forces with the other two workflow interns to become one team #workflow-party-corgis. As it so happened, Michelle and Bryan were really into the controller logic part of the project that Saundra and I hadn’t started yet, so our team came together nicely. Before we knew it, we had the minimum viable product of the very first phase, and it was time to ship our code out to our full team to start getting feedback.
As one might imagine, the first time shipping code to the real life GitHub.com production application is positively terrifying. To be honest, the second time…is also positively terrifying. By the end of my ten weeks I may have been #overit, but the first time had me literally shaking as I pressed the “enter” key. I watched our error reporting dashboards vigilantly, waiting to pounce at the first sign of a problem. At least, I like to think I looked that cool from the outside. In reality, I was just continously spamming my senior engineer buddy with screenshots and varying levels of visible panic, like “is this a problem? what about this one? this one? oh no I broke it. I definitely broke it. oh no oh no oh no I broke it oh god what do I do what do I do oh go-“
At that point, Saundra pointed out that our build hadn’t even finished yet, so our code wasn’t deployed at that point. False alarms, I guess. But, after a few more panicked moments, code that we had written was technically out on an app used by 22 million developers worldwide, even if internal feature flagging wasn’t showing it to anybody but our own team. I have to say, it was pretty mindblowing to see our very own code actually do things on the real-life GitHub.com.
Once we had shipped the first stage to our team, our next steps were to gather feedback, finish the rest of the feature, and prepare to ship it to the whole company. I liked the feedback process a lot, because we got to hear what users were thinking rather than debating what hypothetical users might think. We also used our new feature ourselves a lot, so we got to see first hand what worked and what didn’t. With that new information, we worked with a variety of product designers to shape the user experience that you see today, and in that process we actually ended up with an entirely different toolbar than the one we originally had. Although we went through many, many iterations, each one was a wonderful learning experience for us, as we got to hear from and debate with the pros about real life UI/UX considerations. To mirror a famous quote, I learned about 12 different ways not to make a toolbar, and for that I’m actually super grateful.
Finally, we shipped our feature to all of GitHub staff so that we could collect one last round of feedback before releasing it to the world. In the meantime, we connected with the Support, Documentation, and Editorial teams so that we could share not just new functionality, but a fully useful feature out to as many users as possible. Shoutout to all three of those teams, big time; turns out we were actually supposed to loop them in way earlier than we did, so by the time we contacted them, they had to rush a bit to get everything out quickly. But, despite that, all three did really a wonderful job of packaging up our feature and announcing it to the world, and that was so cool.
The day we shipped our feature to production for realzies, I was actually on a layover between two flights. There I sat in the Detroit airport, video calling with the group as they all gathered around one computer. Slowly, the moment we’d been working towards all summer finally arrived, as our manager eventually clicked the button to release this new feature to all the land, and that moment was …really anticlimactic, honestly. It was like 5PM EDT on a Tuesday, and many developers in the US were probably just humming about, winding down their day. Our analytics data showed one, then three, then nine uses of our feature, but I think by the end of my layover we had gotten just that: nine uses of the feature that I had spent all day nauseous just thinking about releasing. So I got on that second plane pleased, yet thoroughly whelmed.
It wasn’t until later that night, when this tweet happened, that the idea of our feature actually helping real people in real-life work situations suddenly burst into reality. In a fit of overwhelmed awe, I replied with this, and that instantly took off too as people got excited with me. Suddenly I’ve found this wonderful community on Twitter and GitHub of people who support and promote each others’ work, and it has been such an amazing thing to discover.
Overall, I spent this summer learning an incredible amount about teamwork, engineering, working a Real Adult Job, startups, communication, and, incidentally, kickboxing. It’s all entirely too much to fit in one blog post, but I thought I’d at least get this out first, because, like shipping to prod, I think the first one is always the scariest.
Thank you so, so much to everyone who was a part of this journey this summer, especially to my teammates Saundra, Michelle, and Bryan, and everyone else who taught me, either actively one-on-one or more distantly by example. I sincerely cannot find the words to express how grateful I am to have had this experience. Thank you.
✨