DEV Community: Garrett Luu

Opening up to Open Source: the MLH Fellowship Experience

Garrett Luu — Tue, 25 Aug 2020 05:39:50 +0000

Recently, I got the opportunity to participate in the Major League Hacking Fellowship, a 12-week program where fellows work directly with open source maintainers and contribute to open source projects. After getting my internship canceled due to COVID, this became a great opportunity to learn and gain experience over the summer. It definitely wasn’t smooth sailing all the way through; I would say I had a rather unique experience working on multiple projects, getting used to the remote work environment, and learning more about the open source community.

The Code

I can divide the fellowship in 3 distinct phases, each with a different project. Initially, I was assigned to work on SheetJS, a JavaScript library for spreadsheets. I was mostly doing small bug fixes and updates here and there. The biggest task was the CLI refactor I did, which separated command-line interfaces of a few key libraries, and I even got to publish a few packages on NPM!

A few weeks into the program, the SheetJS maintainer decided to launch a new project: WordJS, used for parsing Word documents instead. Working with ODT and DOCX files was very challenging, but it was a nice change of pace from doing 1-line PRs.

Unfortunately, the SheetJS maintainer had to leave the program for personal reasons, and many of us moved to work on Babel Sandbox, an IDE and educational tool for Babel. We worked directly with Henry Zhu, one of the Babel maintainers, who was acting as the “customer,” giving us feedback in weekly meetings after each sprint. In just 4 short weeks, we were able to take his prototype and develop an almost complete product! You can view the site here: babelsandbox.com

The Work

The structure of the fellowship was simple: we were divided up into pods of 8–10 fellows, headed by a mentor. We had daily standups to check in with the rest of our pod members and get help if we need it, and additional meetings with maintainers depending on the project. There were also a plethora of talks and workshops, giving us plenty of opportunities to network and learn.

To summarize this section in 1 sentence: remote work is not ideal. I had always imagined working from home to be a luxury, but it was far from that. Not having a set schedule to start work and stop work meant that it was really hard to find the balance between working and taking a break. To be honest, I felt very unmotivated for most of the fellowship, and it took 8 weeks for me to finally get used to the work environment. Thus, I felt like I didn’t really take full advantage of all of the opportunities given to me and didn’t really get everything that I could have gotten from this fellowship. With that in mind, I still think I learned a lot and had a lot of fun!

The People

While I had previously done open source work (Hacktoberfest — contributed to discord bot Kyoko), I had never really been that involved in the community and worked this closely with other people before. It was incredibly interesting and insightful to listen to different perspectives and voices in the open source community.

Working with the SheetJS maintainer was by far one of the most different styles of project management I’ve experienced. “Trial by fire” was what he called it; we had a learn-by-doing experience where code review was minimal and stuff got merged rather quickly. There were definitely advantages to this system, mainly the accountability; it encouraged me to be much more careful about the code I was writing and committing, and the SheetJS dev was more than happy to answer any questions I had regarding implementation decisions. But the main disadvantage was the lack of feedback; I had no idea if the code I was committing was good and how to improve if it wasn’t. Still, I think it was a worthwhile experience and really made me think about what I like or dislike in management styles.

During our calls and demos with Henry from Babel, we also got some insight on working with open source from the maintainer perspective. Mainly, I was interested in how maintainers balance the “vision” of the project with what the community wants. If you remember what happened with Actix-web, what the community and maintainers want can often differ quite a bit. He mentioned the importance of saying “no” as a maintainer, and how projects can often become diluted over time. However, open source should also be more accessible to encourage contribution, so finding the right balance is extremely important.

Finally, there’s also our pod! Working with everyone has been a blast, especially in the last four weeks as we built Babel Sandbox together. Our daily standups were often the best part of the day for me, even in the difficult weeks where I had trouble finding my own motivation. Ian, William, Barron, Mohammed, Jorge, Janie, Anirudh, Kirby, and Srijon, you all inspire me in different ways to continue to strive and do more.

Lessons Learned

I always try to take away some main points from each experience; if I had to summarize what I learned in a few short bullet points, it would be this:

Motivation comes from within — no project, internship, or job is going to suddenly make me passionate or engaged automatically, and I need to find it within myself.
It’s ok to be a slow coder — better to slow down and get clarification on a feature and write better code than to rush it.
You are not the code you write — the idea of “code dissociation”: writing bad code does not necessarily make you a bad coder, and gives you an opportunity to learn from your mistakes.
Advice isn’t useful until you actually use it — you can listen and learn, but nothing beats having experience.
Dare to explore — it’s ok to try things and realize that you don’t like them, especially this early in your career.

I think what surprised me the most was that the code was the least important part of the fellowship; it was really about learning to work with others, to collaborate, and to really get the chance to explore what we are truly passionate about.

I’m thankful for this opportunity to be part of the inaugural class of MLH Fellows! While I am not completely satisfied with myself and my work, it was definitely an amazing experience, and I still felt like I grew both as a software engineer and as a person.

The MLH Fellowship will be returning for the fall, so if you are interested in applying, visit this page to learn more: fellowship.mlh.io. Also, feel free to reach out to me if you have any additional questions about the program!

Why Am I Studying CS?

Garrett Luu — Wed, 08 Apr 2020 00:19:50 +0000

Originally published on 2020.2.19 on my personal website.

So recently I’ve been dealing with a bit of a career crisis of sorts, stemming from one critical thing I’ve noticed about myself: coding isn’t fun for me anymore.

Honestly, I’m probably experiencing some kind of burnout or slump, but it got me thinking about what I truly enjoy studying. Between learning real analysis, doing reduction proofs, and deriving graph algorithms, I found myself loving pure math. The CS theory classes dreaded by everyone else became incredibly fun. Writing proofs became way more interesting than writing code. I don’t necessarily want to pursue pure math and go into academia though, but the path to being a software engineer now seems a bit more muddy than expected. It got me thinking about why I was pursuing CS and what I was hoping to learn from my classes.

On a related note, I recently came across an article titled “10 reasons to ignore computer science degrees,” which caught my eye as I’m a CS student. The article mentions some key points, including how CS theory differs from software engineering, and how most CS programs offer very little in the realm of practical knowledge — for example, UCSD doesn’t offer any courses on popular shiny new tech such as React or Node.js. While I agree to a certain extent about these claims, the author fails to grasp the fundamental purpose of a CS degree (and university education, to a greater extent): to produce strong thinkers, problem solvers, and engineers, not merely coders.

Before I continue, I just want to clarify what I mean by the terms “engineer” versus “coder.” Isn’t it all the same thing? A software engineer writes code. A coder writes code. What exactly do you mean? I I think it’s best to describe this with an analogy: an automotive engineer versus a mechanic. It’s pretty clear what the difference is between these professions; an automotive engineer might design cars from scratch, while a mechanic is responsible for building, fixing, and maintaining cars. The full breadth of knowledge that an automotive engineer has isn’t really needed by the mechanic. But at the same time, if you ask a mechanic to design a car completely from scratch, he/she might have some trouble. The same applies in the software world.

Why make this distinction? What’s important here is that CS programs are not necessarily meant to produce the best coders, but rather strong software engineers with a very broad knowledge of the field of computer science. It’s very easy to watch a video or tinker with a project to learn the fundamentals of Java, but not quite as easy to learn the concepts of OOP and the principles of OOD.

The other day I had a chat with some friends, and one of them said something that actually got me thinking: “I’m actually glad that this school doesn’t offer a class on something like React, ’cause that would be stupid. You can learn React on your own or on the job, but you can’t learn how to think in the span of a few hours.”

“This is what separates us from people taking free online courses,” someone else added.

In contrast to the article I mentioned, I completely agree with this idea. What’s most important in software engineering is the concepts, not necessarily the tech that goes into implementing them. This is why technical interview questions focus on problem solving rather than technical knowledge. While you don’t (and probably won’t) necessarily use Red-Black Trees in a front-end dev position, it’s still a useful tool to test your thinking and problem solving skills.

With all this in mind, I’m planning on taking a new approach to what I’m hoping to get out of college. Classes are for cultivating my thinking and problem solving skills, while hackathons and projects are for developing practical knowledge and learning new tech. Even with my self-proclaimed dislike for coding, I still don’t have an intention to change careers; I still love everything about CS, and I still want to go into software development. I would just rather concern myself with the high-level concepts rather than the low-level implementation details. I know I’ll get over this phase soon, but it really made me appreciate CS a lot more and think deeper about why I wanted to pursue this field.