Saif Islam

Posted on Aug 31, 2021 • Edited on Sep 11, 2021

MLH, Open Source, Mapillary & Me

#mlhgrad #opensource #career

MLH Fellowship, Open Source, Mapillary & Me

This post goes over my experience with the Open Source MLH Fellowship for Summer '21. 😁

There's quite a lot I want to share with you, so sit down, get some popcorn if you want, and enjoy!

MLH Fellowship, Open Source, Mapillary & Me
Table Of Contents
Hello Hello!
So what is MLH? (Hint: It's not just an 'internship')
How it all started
Some Final Thoughts
Where else can I find MLH?
Connect with me

Hello Hello!

So, to state the obvious, I got accepted as an Open Source MLH Fellow for the tenure of 2021! 🎉

This post details my experiences, the lessons I learned, the people I met, the work I did, and the events/sessions that I participated in, and a whole lot of experiences that I got to be a part of starting from June all the way to August.

I'll be talking about what the MLH (Major League Hacking) Fellowship is, what's it all about, how you can be a part of it in the coming batches, what to expect and how the experience will be extremely fruitful for you to gear start your future career if you're an undergrad like me.

I'll also be talking over what the Open Source community is, some take away ideas that I got from my experience, and then further into what my assigned project, Mapillary is all about, how I contributed to it, and the domain that it helped me to get comfortable with.

So what is MLH? (Hint: It's not just an 'internship')

Before you apply ...

The MLH Fellowship describes itself as "a remote internship alternative for aspiring technologists. Spend 12 weeks building your skills by collaborating on real-world projects." It's meant to be as an remote alternative for students looking to code, learn, collaborate, and be a part of a community!

You're offered (currently) to be selected into one of their three currently available tracks,

Open Source
Software Engineering
Production Engineering, powered by "Facebook"

Each of these tracks are fantastic opportunities to get exposed to an amazing community, and overall really great experience, as all of them focus on,

Remote first - You get to meet people from all around the world
Small groups - Pods of 11 members + Pod Leader
Extra Cirriculars - MLH isn't all about just putting out more lines of code on your project, there's a strong emphasis on being part of a community as well
Technical Mentorship - Mentors and pod leaders are always available to help you if you run into any problems
Career Training - Practice interviews, improving & get tactical feedback on your resume from experts
Educational Cirriculum - Learn industry best practices using tools like Git & GitHub that you can apply to your project

The Fellowship participants are students who filled the eligibility criteria of,

Age - You must be over the age of 18 or over age 13 with your parent's permission.
Residency - You must not reside in a country embargoed by the United States.
Time Commitment - You are able to commit the required hours per week to the program
Communication - You're proficient (enough) with English, both written and spoken.
Coding Experience - You can code proficiently in at least one programming language
Environment - You have regular access to a quiet workspace for meetings & coding.
A/V Setup - You have regular access to a video call quality Internet connection, webcam, & microphone.

... And that's it! You're good to go! :D

Some FAQs First

You must have some questions ...

How I apply to be an MLH Fellow?
- Head over to Fellowship - MLH to submit an application
When can I apply?
- MLH Fellowship has three batches throughout the year, each in Spring (Late Jan - Early April), Summer (Early June - Late Aug), and Fall (Oct - Dec). I could not find the dates for the next batch, but you can usually find them on Fellowship - MLH
Is there a stipend?

If required, yes, there is a need-based stipend to cover basic expenses regarding where you live.

"The amount of the stipend is determined by your track and the country you are residing in during the program"

See Fellowship - FAQ for more information

How much do I need to know code wise?
- MLH assumes you have basic practice with coding already with familiarity, and that you at least are somewhat proefficient in a language. It may be that you do not get to work with your strongest language (I was more proefficient with JavaScript, but worked with Python). If you are not familiar, you will always have the time to pick up new skillsets along the way
How are you assigned to projects?
- The project assignment considers the pod member's interests and alignments. For example, I'm heavily into Software Engineering, and got chosen to work on Mapillary to develop an SDK which heavily employed Software Engineering practices
How much is the time commitment?

MLH expects that you spend at around 25-30 hours with them working the projects and taking part in the standup and other sessions that are arranged. This includes everything from standups, to hackathons/competitions, tech sessions, and 1-to-1s you should be arranging with other Fellowship participants
I would say to not worry too much about it because it can flexible. MLH acknowledges that everyone comes from different time zones, so there is conflict bound to happen at some point
For example, halfway through the Fellowship, I was without my fiber optic Internet for 3 days, only relying on my mobile data for communication and text messaging because of some wire related issues near my home, ad it was perfectly understanble to my pod leader and team mates

Some Terminologies

Each batch has,

Pod - A pod is a group of 11 Fellowship participants, along with a Pod Leader. Don't worry if they would be awesome or not - they're gurranteed to be great people :D

NOTE: If at the time of applying you're not sure if you would be able to carry on with the Fellowship fully because of circumstances of positions at other places and you go on to be accepted, you can go on to drop your seat in the start for someone else.

Also to note that if you drop in early, the MLH Fellowship will most likely be able to find someone else. However, it may not be true if you drop it mid way as it is harder to replace. Please talk to your Pod Leader about your decisions/plans first
Pod Number - Each group of Fellowship participants is assigned a number. Mine was 3.0.1. Each pod will work with a specific technology most likely. For example, my entire pod was assiged Python projects, and another pod was enitrely assigned Ruby projects, another was assigned JavaScript projects, and so on
Pod Leader - Your pod leader is responsible for leading your daily standups, informing you about updates in the program, anything or mostly everything you may need to do, and assist you in obstacles by arranging 1-to-1s. Feel free to talk to Pod Leaders about basically anything (yes, I mean it).

Feel relaxed to talk about career, life, the project you're working on, anything (I cannot stress this enough) that is troubling you, anything you want to ask, any ideas you want to share about your pod or anything you would like to see happen. Pod Leaders are mostly past fellows as well, and want to make sure you're enjoying the Fellowship as you're going into the process

Trainual - Each week has a trainual where you have to at least write up about how your week went, what work you got done, and what you're planning to do next week. It can have other modules as well, such as Git, GitHub, and other training as well

Open Source

Fellows on this track contribute to open source projects, sometimes building projects from scratch (such as mine), sometimes contributing to extremely well known projects (see below).

At the time of writing, the Open Source track has included so far the following OSS projects such as,

AWS Amplify - The AWS Amplify CLI is a toolchain which includes a robust feature set for simplifying mobile and web application development. The CLI uses AWS CloudFormation and nested stacks to allow you to add or modify configurations locally before you push them for execution in your account.
BentoML - BentoML is a flexible, high-performance framework for serving, managing, and deploying machine learning models.
Dfinity - "Infinite Blockchain That Serves The Web", the DFINITY Foundation is a major contributor to the Internet Computer
Facebook's Antlir VM - Antlir can reproducibly build, test, and run OS images for containers and hosts.
Facebook's Mapillary - Mapillary provides hosting, processing, and publishing street-level imagery and map data easy on a collaborative platform!
Facebook's Pysa - An open source static analysis tool to detect and prevent security issues in Python code
Facebook's Stylex - Topics covered include Facebook's approach to CSS-in-JS, data-driven dependencies, phased code downloading, and more
Facebook's WebXR - This specification describes support for accessing virtual reality (VR) and augmented reality (AR) devices, including sensors and head-mounted displays, on the Web
Forem - Forem is open source software for building communities. Communities for your peers, customers, fanbases, families, friends, and any other time and space where people need to come together to be part of a collective. See our announcement post for a high-level overview of what Forem is
Howdoi - howdoi provides the solution to the question, "Are you a hack programmer? Do you find yourself constantly Googling for how to do basic programming tasks?"
Jina AI - Build and deploy your AI-powered search applications in seconds with Jina’s open-source tech stack
JupyterLab - Project Jupyter exists to develop open-source software, open-standards, and services for interactive computing across dozens of programming languages
The Pallet's Project - The Pallets Projects are a collection of Python web development libraries that were independently developed by Armin Ronacher and later used as the basis of the Flask microframework. Today the Pallets Projects are a community-driven organization with the goal to maintain and improve those libraries

As for the question of "Is this for me?", you can think about the goals of the track and if they align with you.

The main goal of the Open Source track is to familiarize you with,

How the Open Source community works and how you can get started with contributing to major projects
Help you get started and build your confidence up to merging more and more Pull Requests on the projects you love and use
To hopefully make it so that you'll still be contributing and be a part of communities after the your tenure ends

The Open Source experience for me helped me to either learn about or contribute to more than 3 projects in my spare time simply because I know knew more about what goes and what doesn't go in the community, and how to take the right approach with it. It made me more positive about my contributions, regardless of how small or large they were.

Software Engineering

Working on a project in agreements with a "corporate or government partner". Unfortunately I don't have too much knowledge about this. Check out the Software Engineering track here.

Production Engineering

The Production Engineering track is designed as an educational track to learn more about the PE role at Facebook. This track included learning technologies all about the role, tools such as Nginx, Docker, Prometheus, Grafana, CI/CD Pipelines, CAdvisor, GitHub Actions, AWS and more!

During my tenure, this track was only limited to North American participants from Canada, USA, and Mexico.

The PE had many weekly talks from the teams at Facebook, a small sneak peak includes talks about,

Production Engineering vs Software Engineering
Monitoring Concepts & In Action At Facebook
Building Scalable Infrastructure While Still In School
Recruiting Talks & Resume Tips
Joing PE From Diff/ Career Backgrounds

Fellows in this batch have to develop a project using many of the technologies taught as part of the cirriculum as their final deliverable with a project demo at the end.

Most of the talks are geared towards PE Fellows, but anyone from any track and any batch can come and be a part of the talks!

As for the question of "Is this for me?", you can again think about how close you relate to the goals of the track

The main goal of the Productin Engineering track is to familiarize you and introduce you to,

Concepts of Software Architecture, Site Reliability Engineering, Software Infrastructure & Engineering, Cloud and DevOps
Industry professionals who can better cater to questions regarding the field and how you can start working professionally in a PE role
Building projects with the aforementioned tools to demonstrate capabilities as a PE enthusiast
How to keep pursuing as someone who loves to build Software Infrastructure, and putting projects into production

Raise Dev & MLH Fellowship Sessions (Internal)

Being a part of MLH offered me the chance to arrange sessions with mentors on Raise Dev, which made it easier in my tenure to go and talk to industry professionals for anything related to,

Career Advice
Resume Feedback
Pair Programming (Yes, seriously!)

There was also the added benefit of internal MLH Fellowship Sessions that fellows get to experience and ask questions in.

Some examples of the talks are,

Cracking The Coding Interview (CTCI)'s series by Kunal (fantastic guy, fantastic sessions!)
Cloud & Cloud Native Sessions (Monitoring, Prometheus, K8s No Code Contributions, Machine Learning, Service Meshes etc)
Open Source, Developer Advocacy, DevRel, Tech Industry Networking, Career Growth Advice, Hacker Culture, Data Governence, Julia and so much more!
Sponsored talks by Jina AI, Remote, Microsoft, DataStax, GitHub, Facebook and more!
Technical talks such as Emphemeral Hardware, Serverless Video Confereing Application, Docker, Pallets, GraphQl, and of course, more.

My thoughts

I wouldn't use the word 'internship' to describe the experience that I had because the word seems very traditional in that it conveys the idea of something you're work on in a given time period on every weekday for a determined period.

For me, I would say, it was three different kind of experiences complimenting each other.

Firstly was the getting to know people from all around the world, being able to attend sessions and talks for all topics tech and community wise. It was about making friends, seeing what others are doing, getting to know people, sharing experiences, being able to understand so many backgrounds and perspectives and learning from everyone around you.
Secondly was the project that I was working on, the completely new domain for me, the company, the project, the remote work environment, everything was very new to me and very surprising.
The community experience of finding new folks and taking part in events or competitions and getting better to know each other and their expertise. This extremely helps you to get your hands dirty that you might otherwise be hesitant about, and has the immensely added benefit of networking and getting to know sooooo many talented people!

All of these make the MLH experience very unique and helps you figure out not only how to work better in communities and in teams and how to communicate, but also exposes you on how to get help if you're stuck and how to share your problems.

Delaying it no more, below is a more in depth on how I winded up at MLH.

How it all started

For my story, I stumbled across Major League Hacking accidentally one day while randomly scrolling my LinkedIn back in The main goal of the Open Source track is to familiarize you with,. I saw students like me from across the world share their experiences on how the journey through the MLH tenure has been for them, and going through that, I said, "Hey, this looks interesting!".

Besides, I myself wanted to dig deeper into the Open Source Community, but I had no idea where to even start. I took out some time to research more into what the whole fellowship was about, and how I could get involved.

The Application

I submitted my application on Sept '20 to be a fellow in Spring '21.

To others, I would advise applying early to the programs ... but I've found people who applied very early and got accepted, as well as folks who applied late and still got accepted. Though it is generally recommended to apply early, my opinions are to apply when you're ready to show something you've made to showcase what you know.

Below are my thoughts on how to approach writing the application, but feel free to add or remove any thoughts from your own perspective,

Don't worry about being not enough technical to start the application. The Fellowship is a learning experience for every pod member involved - no one knows everything
Don't focus entirely on technicality. The Fellowship puts emphasis on building a community, getting to know people, investing time in supporting, helping, and learning from others. Share your experiences about what you've made previously and why it matters to you, what makes you happy and excited in the work you do, and what is it about the fellowship that intrigues you? Be sure to enjoy, make friends, and get to know other people in the Fellowship experience!
The answer to "Why do yo want to become an MLH Fellow" can vary, but it's really trying to ask "what brought you to technology and programming?" "Why is a community important for you?" "What kind of discussions or ideas can you bring to your pod?", and "How can MLH help you in your learning?" Even "Are you familiar with the Hacker Culture?"

The Code Sample

In the Application, MLH asks you to submit a code piece that will be overlooked by their team and asked about by the interviewer in the 2nd interview.

I strongly believe you should show a project you're very proud of, and that you've put a lot of thought into designing, working, to getting it up and running. It doesn't have to be the most amazing idea, but here is what I recommend you show,

It is useful and tries to solve problem. Nothing very big, but targets an interesting problem, like a hackathon idea
Uses some API or does something very cool with different technologies
Has questions interviewers can ask over why somethings are the way they are

Below are some code sample requirements from the application

Here are some things that you should do,

Prepare a neat and organized GitHub README that instantly helps readers understand what the project is about. Remember, presentation is as important as the project itself. If it's too clumsy, or too spreadout everywhere, or you have to explain things that could have been otherwise been in the README, maybe there is a chance for improvement. Here are some links to help with that,
1. How to Write a Good README File for Your GitHub Project
2. Awesome READMEs
Follow some Software Engineering "best practices" (opionated, can be anything you can thnk of that makes fits your project),
1. Modularity - Split logic amongst components, each component doing one thing only so it is easier to explain, modify, and read
2. Practical Names - Obvious, but make sure you name your files and folders accordingly. I personally go check out VSCode's Material UI Icon Pack Theme and see which are some popular folder/file names
3. DRY (Don't Repeat Yourself) - Consider how you generalize similar ocurring problems in your codebase, and talk about how you managed to reduce effort and coding time by having a single point of use
4. CI/CD - If you're familiar, setup some GitHub actions that automate tasks for you to save time
5. Formatter/Linter - Consider using a formatter or a linter for your project to ensure consistent indentation, possible naming problems, possible bugs. This makes your code look clean and easy to read regardless of the codebase's size
6. Testing - If you can, try following a TDD, Test First, or Unit Test approach that help with making sure your project does not break as you keep developing
7. Packages/Libraries - If what you've made is akin to a package or library that can be installed (like a Python Package), prepare a demo to showcase what your project does and how it has managed to solve problems
8. Workflow - If you've worked with other collaborators to develop the project, showcase your methodology of how you get work done if you can. Maybe it is a Jira or Atlassian board, maybe it is a GitHub Issues/Pull Request methdology, maybe you're using something like Travis CI for a CI/CD pipeline, etc. Talk about how you solve problems and conflicts in the project, and how you keep focused on the project you're working on
9. Software - Showcase what technologies you've used in your project, and why. How did using that technology solve a problem you were facing

You DO NOT have to get everything right and perfect. Remember, it's okay to not have everything. A wise man once said to me,

"Focus on your strengths. What you may get done in what you're strong at may only take you 1 hour, what you get done in what you're weak at, may take more than 10 hours"

Pick your battles wisely, don't stress out about it, make something you enjoy and love, and show that to the world!

If you're wondering what my project was, it was Terrabuzz, a "social media application" I made in my last Fall Semester '20 in a team of 3.

It had,

Register/Login/Forget Password/New Password/Verification
Profiles/Following/Followers
Posts/Likes/Comments/Notifications
Settings/Changing Passwords
Search For Profiles/Search For Hashtags

And was dockerized completely and prepared with a Azure VM at the end of a CI/CD pipeline.

Check it out below!

Rubix982 / Terrabuzz

Social media based on connecting users on the basis of interests, integrating a system of news-feed, following/followers, notifications, profile updates, and a basic settings page

Terrabuzz - A Student Social Media Application

Rubix982, Saif Ul Islam,
Hassanzhd, Muhammad Hassan Zahid,
TashikMoin23, Tashik Moin Sheikh,
HasanBurney, Hasan Burney

Terrabuzz

A student social media project
Read the SRS/SDS»

Video Demo · Report Bug · Request Feature

Table of Contents

Description
About The Project
Screenshots
Demos
- Run Demo
- Workflow Explanation
File Structure
- Client
- Data
- Docs
- Server
- Web Server
Getting Started
- Prerequisites
- Installation
Roadmap
Contributing
License
Contact
Acknowledgements

Description

Finding relations among people is one of the hardest things to do with social media these days, contrary to the word social media in the first place. More and more emphasis is put on driving a great amount of reactions, rather than focusing on helping people find more connections far more easily than others.

What does this mean? It means that there are lower chances or possibilities for artists, small business, startups, to more easily connect with their audience Social…

View on GitHub

"Everything You Know About Tech Internships Is Wrong" - Mike Swift, GitHub Education

Check out this short (~16 minutes) talk by Mike Swift over some ideas about technical internships!

GitHub Education

The Interviews

This section describe the interview process, but overall, keep in mind to,

Relax and don't stress yourself out for the interviews!
Please be yourself and feel free to communicate better and focus on talking and asking questions if you like
Don't be afraid to express and talk about your personality. It does count and it is valuable as a Fellow (remember, it's not all coding)

The interviews were in two parts! They are as,

The first one is a no code, no project, 10-15 minute interview for eligibility filtering. It describes itself as,

During this call we'll be confirming your eligibility for the program and evaluating your ability to successfully participate. If time permits,
you'll have an opportunity to ask questions at the end of the conversation.

What we're looking for,

Eligibility: Do you meet the criteria for the program & understand the commitment?
Passion: Why do you want to become an MLH Fellow and what will you bring to the batch?
Communication Skills: Will you be able to successfully collaborate with other fellows?
A/V Setup: Do you have a remote environment that will allow you to successfully participate?
Professionalism: Did you show up on time and demonstrate a high level of professionalism?
The second one is a more technical sided interview about the code submission made in the application.

It is recommended that you freshen up on the codebase, the architecture, design and tooling decisions and have the project in an up and running state. It describes itself as,

During this call we'll be walking through the code sample you submitted, discussing how you built it and what you would do differently in the
future. We may also ask you some questions about your familiarity with the specific technologies & programming languages you indicated you were
proficient with on your application. If time permits, you'll have an opportunity to ask questions at the end of the conversation.

What we're looking for,

Technical Proficiency: Do you have a proficient understanding of the language you used
Learning Potential: Do you respond well to feedback and have an aptitude for learning?
Communication Skills: Will you be able to successfully collaborate with other fellows?
A/V Setup: Do you have a remote environment that will allow you to successfully participate?
Professionalism: Did you show up on time and demonstrate a high level of professionalism?

The Process

So come around December, I've given my interviews and am now waiting for a reply. Sadly (actually thankfully), I get redirected for the next Summer batch.

Thanks again for applying for the MLH Fellowship: Open
Source (Spring 2021). Unfortunately, after careful review,
we have decided to reject your application at this time
because we were unable to match you to an opening on one of
the Pods. However, we were significantly impressed with you
and your application and we would like to invite you to
enroll in a future batch of the MLH Fellowship in the Open
Source program.
...

Honestly, at that time, I didn't think too much of the rejection, but still kept at eye out on the MLH Discord channel to check for updates now and then.

Now comes May, I still had time and hadn't really planned what to do with my Summers. I was applying for internships around me, but getting few replies, if any ...

... Then on May 7th, I get an email from Mike Swift himself asking me if I'm still interested, and for what track. My response being, "I'm interested in being considered for any track of the MLH Fellowship", and then finally on May 11th,

I finally get accepted! 🎉 🎉 🎉 🎉 🎉

Starting Out

My tenure officially started on June 7th (in the middle of my final exams :horror:) but I was luckily able to manage both until June 23rd when I was finally free and available to get work done. 🔥

So to get started, I was invited to the MLH Fellowship Discord channel through an email, where I was assigned to the 3.0.1 "pod" for Python projects.

A "pod" is a group of 11 people + the pod leader that meets up everyday. Everyone updates what is it that they're working on, what have they got done, what blockers they're facing. At the end of each week, we also have a "retrospective" where we talk about how the week went. In this, we talk about,

Greens: Things that went really went and don't need any help from others
Yellows: Things that can go better than they have, help or advice maybe needed
Reds: Anything that is a blocker or major obstacle preventing progress

My pod leader was Gabriel De Melo Cruz, a super friendly lead who really helped everyone feel comfortable about the fellowship experience and really coordinating with basically everything we had and did.

(Also we named our Pod, "The Callback Camels" which you can see the background)

Standups

We had standups!

We did it in two ways,
1. We had a post on a MLH Fellowship GitHub page where we had to fill in the format,
  What did you achieve in the last 24 hours?:
  -
  
  What are your priorities for the next 24 hours?:
  -
  
  Blockers:
  -
  
  Shoutouts:
  - @username for x
2. The first 20-30 minutes of the hourly meet from Mon-Fri would be about describing the standup in more detail, give shoutouts, ask questions about anything basically
The remaining time that we would have, we would spend it on "Show & Tells", discussions, projects, trainual, arranging mock interviews, Resume discussions, sometimes playing games like Scrible or Among Us if there's enough demand. :P
Everyone was asked to arrange Calendly 1-to-1s to get to better know everyone else in the pod, so it was pretty common to arrange 1-to-1s with everyone, even from outside the pod

Meetings

As above, you'll be asked and heavily encouraged to arrange 1-to-1s with other pod members, even other members. Setting up 1-to-1s included,

A Calendly account and sharing that other pod mates
Your Pod Leader throughout the Fellowship
Mentors from Raise.dev
Pod Members/Pod Leaders from other pods

Orientation Hackathon

In the first week of the MLH, we went through the Orientation Hackathon where we had to build a hackathon project, with a submission till the weekend. For my presentation, I teamed with up two amazing people, Gabriel B. Saint'Anna, and Giancarlo Fissore, and we built Crowd Sourced! A platform where users could potentially upload unlabelled data, which would be labelled by contributors.

"Open source "ML As A Service": high quality labels to train your models!"

Project Assignment (Mapillary, Facebook Open Source)

And finally starting from the 2nd week, we were assigned to Open Source projects to work on during the Fellowship.

I got selected to work on Mapillary, an Open Source alternative for better maps by providing access to street-level imagery and data from all over the world. Currently it's under Facebook's Open Source program, which was huge for me to be a part of.

First, a bit about Mapillary. Check out,

My project was the Mapillary API v4 Python SDK, an SDK designed to interface with Mapillary's latest API v4 Release. For this, me and my team mate, Omar, were given a "Product Requirement Documentation" with 12 base requirements, and we had to translate that into a working SDK for GeoSpatial and GeoInformatics users.

In regards to the API, we worked with with,

Images
Map Features
Detections
Organizations
Entities
Vector Tiles
Traffic Signs

We had to use libraries such as mercantile, mapbox, shapely, and turfpy to implement the core functionality.

In the process of all this, learn about GeoSpatial/GeoInformatic concepts to better interpret what we wanted to see in the SDK. This was an amazing experience as I got to touch a new domain because of this project.

In the end, we designed and finished with an SDK that,

Has more than 9K+ lines of contribution
Currently 53 PRs, 46 merged, 5 closed, 2 open
Issues racked at about 51 closed, and 19 open
Made small releases on PyPi. We're currently trying to fix bugs for the documentation so it is visible properly so we can release 1.0.0.
Has a working Jupyter Notebook (Colab) demo!

During the process, we,

Developed and provided interfaces for the 12 requirements
Created a CI/CD PyPi release mechanism
Developed automated testing with PyTest on every merge and PR
Followed Software Engineering best practices by employing ideas for maintainability, code readability, compatibility, testing, documentation, and release management
Implemented feature requests and used modularity to split utilities, configuration, models, and controllers (for business logic)

Unexpected Contributions (Jina AI, Neural Search Engine)

Having some past experience in Docker, I got to know from my podmates, George McCarthy and Giancarlo that they were working on a Protein Search project using Jina AI to demonstrate the protein seraching capabilities, and that they wanted to dockerize the application, but didn't know exactly how to ...

... So I spent some time working on their project as well, and contributing to it to make it completely dockerized so that it is very easy for anyone to pick up the project and use it

Show & Tells

We had Show & Tells! What they basically are is that everyone has to find something that they're working on or learning about, and share them with rest of the pod. It can be literally anything, for example, the "Show & Tells" for my pod included,

Dicussion on Cal Newport's Book, Deep Work by George A. McCarthy
Digital Art, by Jyoti Bisht!
Animation, by Sheza Munir!
Vim, by Giancarlo Fissore!
Bashed "Hack The Box" demonstration from Gabriel Cruz!
How to optimize Fibonacci using Scheme, as a demonstration of optimizations problems from the Structure and Interpretation of Computer Programs, by Gabriel B. Sant'Anna!
DevOps (me)!

Towards the end of the Fellowship, we came up with the idea of giving a presentation about the project that we've been working on in the Summer as well!

Capture The Flag

So MLH has started this tradition of doing CTFs which are basically brain teasing, hands-on security/networking related questions in where there is a string format hidden somewhere in the problem, and you would need to find it. The format can be anything, but in our case it was mlh{ANYTHING_CAN_COME_HERE}.

Approaching the last two weeks of the Fellowship, this was mostly of what I was doing, and trust me IT WAS HARD, but my team finished 9th out of 33 teams. :happy:

Here's one, see if you can decode it,

SIISIISISIISIISIISISIIIISIISIISIISISIISIIISISISISISIISISISISIIISISISISISISISISISIIIIISI

Some Final Thoughts

So before we conclude, there are some thoughts I want to share,

Imposter Syndrome

This may sound shocking, but I honestly had NO expectations of getting selected into MLH. I saw the work that everyone was doing in MLH, and I thought,

"I'm no way that good at those kind of things"

But I applied anyway because I didn't want to not submit an application regardless of the chances I had.

In fact, I had more hopes of getting accepted at other places rather than MLH, but I got rejected over those, and accepted here.

And as a shock, I was completely taken by surprise when I did get accpted through an email.

And that ended up causing a bit of a Imposter Syndrome panick in me. In a few days and after a few standups, I found out each of my podmates were suffering from Imposter Syndrome as well.

So here's the deal and breakdown on how to "accept" it - there is no real way to remove it, but rather how we react or think about it that makes all the difference between being confident and eager to learn anything and everything, and the opposite end which is being very cautious of learning and trying out new things. Here are a few things to break that mindset,

No one knows everything. They just don't. Through the Fellowship, I found friends who would talk about Machine/Deep Learning, while some of my friends would take about Digital Painting and Animation. Some talked about writing and music, some talked about philosophy. What one friend of mine knows, the other just doesn't, and vis a vis.

The point is to be comfortable with what you know, and enjoy the learning and growing phase of that

Don't worry about finding it time taking to learn new things. Again, the point is to give yourself a pace that works for you, it doesn't have to be necessarily on par with others

If you don't know, you can always ask! If you don't feel comfortable talking about something to someone, there is always someone in the Fellowship that can help you with your worries
Everything takes its proper time. Some things take hours, some days, some weeks. Do not be too hard on yourself to adapt to everything very rapidly. At one point doing the CTFs, I found myself angry at my own self because I was not able to quickly solve problems as much as my team mates, so I asked my lead Gabriel, and this is how the conversation went,

Me:

I'll be honest

I'm scared of competitions

Because I have to keep reminding myself to enjoy and learn from the process and not worry about the scoreboard

For some reason, it makes me think again and again if I'm not able to push with progress on something

So I've never really learned to solve problems I think the way that they should be

Have you ever been in something similar?

Gabriel:

All the time
One thing that helps is doing different things

Like parkour shows me a lot about these things you know

There's always a challenge that you'll do (either because you have better balance or you jump higher) that the other person won't. But then
5mins later you'll face a challenge that the other person (because they're not as tall as you, and that becomes an advantage in that particular
challenge) will be able to do

Another thing that could be happening is that you're focusing on the solving part of the "solving problems"

Solving problems is never about the solution itself, but rather how did you get there? Would you be able to solve similar situations using the same
techniques? Why? Why not?

Focus on the learning

And I would say the same, to focus on how to get to your goals, rather than what the goal looks like currently for you, and you might learn a lot more than you initially expected.
Trust yourself and the process - everything works out eventually

Open Source Misconceptions

Before I end, there are a few Open Source Misonceptions I would like to say,

You DO NOT have to be super technical to get started in Open Source. Contributions can mean anything from writing tutorials about that Open Source Technology, the documentation, helping with the release engineering, providing advice about new features and giving user feedback, staying in the community and getting to know other developers
Get to talk to the maintainers if you really wish to spend considerable time on the project. They will really help you speed up the process to start contributing to the project, and would be more than happy to help you in anything you come across. No one knows the project as best as them.

Think about it like this, Open Source projects are only as popular as the number of users using them. If tomorrow suddenly, less and less users started to adopt and learn React, it wil start to become legacy codebase, with few improvements, community participations, and code contributions.

FOSS projects only live as long as the users using them and the maintainers maintaining them
Being honest, Open Source takes time. I realized I did not start seriously contributing to Open Source until I found people who were contributing to Open Source as well. This made me realize to find communities and "developer spaces" that encourage and work within this space. So if you're someone who's just starting out, I would heavily recommend getting together with friends or finding a community near you, where you work or study, and get to gether to work with them. Working together with someone gives you some great benefits,
1. You have someone to rubber duck to. If you go out and find people who you can talk to about your FOSS project, you'll rapidly realize how hard and time consuming it can be to have someone understand everything you're saying in one go, much less understanding how they can help you.
2. Working with someone on the project can keep you on track with the actual intended goal, and helps to realize again and again where the direction of the project should go
3. You can't know everything about everything, and even if you do, you can't always make it right. Software is extremely tricky, and you'll end up writing code in one month, which you'll describe in the next month as,
  
  "This is messy, unorganized, and could have been way better"
  
  Followed by,
  
  "Who wrote this code?!"
  
  And you'll realize, it was you all along. If only you had an extra pair of eyes to helpy you catch that bug/issues/feature/feedback sometime before, that would've been great ...
Not everyone is the same skill level, and not everyone is able to give you consistent results as always, and that is OKAY! Please do not alienate people or spread the culture of "I'm better than you". If you feel that is such a case in the FOSS project you're working on, it might end up harming the work culture in the team and give rise to bad, unhelpful, not productive ideas and workflows and isn't helpful to anyone
Always be respectful to anyone maintaining a project out there. Working this Summer on a project from scratch made me realize how many problems and ideas each developer has to consider before they write or contribute anything. Always be appreciative of any and all efforts, and be sure to motivate them as much as you can to contribute more!

All of this leading to my next opinions on ...

Developer Relations, DevRel, Developer Advocacy

If you're into Open Source and Community Building, you should look into DevRel and Developer Advocacy Roles. Period.

I think others have better a much better job than me to explain DevRel.

Here is Eddie Jaoude on How to become a DevRel? Tips + stories from the Flyless community.

How did I feel working on the project?

Coming into the project I was assigned to, I was kind of scared because Facebook is a gigantic company which made me feel I should deliver a lot of results. Over time, these fears stopped because I was given room to find my own pace and ask questions. I was able to share what blocked me, discuss the direction of the project, and share new ideas. I felt closely involved in the project and invested in how it would work out.

I am eager to see how the project works out down the road, and how I can still help maintain it and move it forward. After spending a lot of time on a project like this, you really want to see it succeed. Just this week, someone not from Mapillary, not from Facebook, wanted to contribute to the project. It made me extremely happy to see this, as well as seeing new traffic coming into the project repository. It definitely feels like I've made something very valuable for others!

Do I think I made meaningful contributions to the project?

Because it was a completely new domain, I learned about GeoSpatial data and GeoInformatics, as well as new Python libraries and processes like Structure From Motion (Open SFM). I improved on my software engineering ideas and my thinking about how to design an SDK. I also became accustomed to working remotely professionally. Finally, I met some fantastic people on Mapillary's team and learned a lot from them about their work.