Opening up to Open Source: the MLH Fellowship Experience
Tags: mlhgrad, opensource, career, javascript
Published: 2020-08-25 05:39:50

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](https://babelsandbox.com)

![Babel Sandbox](https://dev-to-uploads.s3.amazonaws.com/i/ofni1muqpd9h0mbk0tvg.PNG)

# 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](https://github.com/actix/actix-web/pull/968), 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.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/vfhx2c74yjw1hkeg2ck9.jpg)

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](https://fellowship.mlh.io/). Also, feel free to reach out to me if you have any additional questions about the program!