A CMU student from icy Pittsburgh and a native of sunny Singapore, Clarence found a nice middle ground in SF for the summer. He snowboards, surfboards, and skateboards and in his free time, he wonders what other boards he can try.
Clarence joined the open source team this summer. After doing some initial work on improving how errors are handled across the Apollo stack, he spent a majority of the summer implementing the @defer directive in Apollo Server and Apollo Client. A long-awaited and powerful feature, Clarence designed and built out it out in collaboration with many Apollo community members and our open source team. His work was released in the last few weeks of his internship and you should try it out!
Interview
How did you get interested in computer science and open source?
I was a beneficiary of the open source community. I wasn't an active contributor, but I used a lot of open source tools and it was an important part of me learning about computer science. If I was growing up 10 years earlier where there wasn't such a thing as GitHub or open source code it would have been a very different route for me. Nowadays things are so open and there are many different routes you can take to learn about CS. I only started CS about 4 years ago.
The first web app that I built was already in the golden age of JavaScript. I came in with some context on these JS tools which eased in my entry a little bit. That's what got me interested in open source, and more specifically web frameworks.
What are some of your earlier projects?
In my first year in college I built this version of Hacker Rank before Hacker Rank existed. The idea was that you could create an online coding environment and you could do live coding with JavaScript and compile it against your test cases. It's a classroom management tool and instructors can see who is falling behind and leave comments.
I was really happy about the project because it taught me so much more than what I was just learning about in school. It was our learnings coming to life. You had to figure out how to deploy it, etc. I used Meteor for the project and it was a great fit for our project. Meteor makes it really easy to get started building simple apps, so all my hackathon and college apps were built with Meteor. It made it feel like something that would be especially rewarding to contribute to, lowering the barrier of entry into the developer experience.
How does it feel to be on the creation side of the open source tools you use?
I worked on this project to implement @defer in Apollo this summer. It helps users split up their queries so that they can load partially. It's rare to have an end-to-end project like that, where the end goal is very directly the user experience. In open source work we're not frontend developers, but a lot of the work we do is frontend work because the work that we do impacts frontend developers. It's interesting and challenging as well, because to make any changes you need to understand the full stack, from the GraphQL execution layer to server and the client. All of those things are complicated software elements that a lot of people have contributed to over the past few years. A lot of my time was spent reading source code and trying to understand why things were designed the way we were.
How did you manage open source collaboration over the summer?
A lot of ideas that I put together this summer were things that a lot of other people had given me input to. They pointed me to resources and things to read. My most productive week this summer was our Everyone In Town week, which is really a testament to how everyone's minds coming together is much better than just my own. We had a whole week of freeform discussion and everyone coming together and white-boarding about how these things could work. It was really great.
The feature design process is talking to a bunch of different people, and I saw my job as just documenting all the thinking that goes behind things so that someone outside the process can look in and read my documents and understand quickly.
How do you think about the impact your open source work will have on the future of our industry's development?
We want to be a force for good. The biggest force for good we're trying to drive right now is really simplifying application development. Our initial wave of success came because our tools were very simple to use and people liked our APIs. This strong sense of user focus is something we need to carry forward and share. We want to be present and have easy touch points for every developer with all of our tools.
What was it like to work on the open source team of a company that also has a commercial aspect to it?
There's been a lot of talk about our user's mindset lately and it's been great to start to see the messaging emerge that Apollo isn't just a SaaS company that charges for every individual query you send, but rather it's a platform that you can adopt. While in the past Apollo's toolkit has consisted of many different parts, it's starting to become more of a unified thing. It's important to take a step back and look at the company's entire message and get that alignment, so everyone can make the most impact possible.
What advice would you give to someone considering coming to Apollo?
I think my biggest advice would be to be curious and not be shy to ask questions or ask for help. A lot of the team members are remote and famous open-source contributors, but they are all very open and willing to help out around any questions you have. Everyone really wants to help and see you grow. There is a lot of value in hearing ideas and thoughts from someone who has been thinking about these problems for a while
What was your favorite part of the summer?
The whole thing! I really liked that everyone would hang out and work in the kitchen together. It was a really nice feeling that we were all thinking about and working on the same things. I also really liked the Everyone In Town week. You realize that all the people you don't get to talk to regularly are super cool and have awesome ideas.