Tell HN: How to contribute to open source as a junior engineer

19 points by Shindi ↗ HN
Hi all, just wanted to write a brief guide on how to contribute to open source.

Saw a thread from a new engineer who wanted to know how to prove that they can work fully remote in order to get a fully remote job. Getting these type of jobs are harder as a junior employee because you don't have a track record.

Contributing to open source demonstrates you go out of your way to improve code, can make changes to a new code base on your own, and can ask for help to get unstuck. Not only can it help you get a remote job, it'll improve your chances at getting prestigious jobs.

I made a few small open source contributions and made some mistakes so want to share what I learned.

1. Find a good project

What is a good project? One looking for help, in a language you know, and where you can get the project running on your own.

If you look around github, you'll see some projects have issues with a Needs Help or a Good First Issue tag. Someone on the project thought that these issues are small and self contained enough to get your feet wet.

Another good sign to look for is that the project has recent commits and is active.

2. Find a mentor

Before contributing a change, you should ask someone whether your plan makes sense. Just like in algorithmic leetcode style interviews, you should never hop in and write code right away. You should explain your plan in plain English, and get the interviewer on the same page.

Likewise, if you see an issue you think you can help and have an idea for how to fix it, write out your plan and ask an existing contributor if you can take on this issue and if your plan makes sense.

You'll save yourself so much time discussing before writing code, and you get to network with contributors of projects. I would have saved so much time if I had discussed first instead of trying to implement my own ideas.

protip: if the project is owned by a company, the employees typically have to help you and contributing to their project will give you first dibs on jobs.

Projects typically have discords or community pages where you can find discussions and find mentors. You can try DMing relevant people (see who contributed via git blame) and straight up ask if they can help you implement your change.

tldr: find a good project with good first issues, find a mentor before writing code, ..., become a legend.

Hope this was helpful!

14 comments

[ 3.2 ms ] story [ 42.2 ms ] thread
In FOSS, there is no ranking. There's no such thing as a junior, senior, principal, architect, staff, or distinguished engineer.

In it's purest fundamental form, FOSS consists only of minds collaborating and working together to negotiate the ascent and realization of a shared objective. Compared to $dayjob, it's beautiful this way. It doesn't matter who's behind the wrench used to tighten the bolt.

Hopefully this can inspire those who perceive themselves as "junior" to step up and learn how to dig in to produce a good result!

It can actually be remarkably fun to try getting a PR accepted to a project that genuinely interests you, and the core maintainers are generally very appreciative of such efforts.

<3

I love this framing. Own your impact. The best software engineers are relentless in their problem solving approach independent of outside judgement, and have some intrinsic drive to find good solutions (ie. even if it's just a day job, they still care about the quality of the work). Sure, mentorship is nice if you have it, but you also need to make your own mistakes and develop first-principles thinking so you don't just cargo-cult whatever you are hearing from "seniors" (there are plenty of bozos with big titles).

I feel like young software engineers are way more tentative and fearful of mistakes than earlier generations. My hypothesis is that this is a result of the massive amount of information available on the internet today and so many self-proclaimed experts ready to pass judgement. But all that's a lot of noise that can feed imposter syndrome and lead to analysis paralysis. The most important person to judge your path and your abilities is you yourself. What will you make today?

How many lines of code?
Contribute to documentation, that's a good place to start and constant effort is needed to keep things up to date :)
You don't even need to contribute to the code: a lot of open source projects desperately need better documentation, or just better copy in their user interface. You can start by literally correcting typos and updating broken links, and your contributions still could be extremely valuable to the project.
Absolutely, and it's a great way to win brownie points with the maintainers.
I'd downvote this post if I could. It's pushing people into OSS contributions only to land jobs. My advice: if you don't subconsciously feel like you want to contribute, don't do it. As to how to start, pick a small bug, typo, lacking documentation aspect, small missing feature or performance issue that annoys you in your everyday FOSS software and solve it.
> only to land jobs.

so what?

This is completely the wrong forum to post this kind of bullshit spam.
Very helpful advice! Mentorship is key for new contributors. Reaching out is a worthwhile skill to master in open source development.