Just like any spoken language, you must constantly immerse yourself in the language and culture to speak any programming language fluently. By dedicating a portion of my time to a single project, I force myself to come back to difficult tasks. Instead of abandoning a project for a new idea, I have a set amount of time each day I work through the problems I was facing yesterday. Dedicating yourself to a project builds grit, and you are more likely to finish bigger projects if you are already used to the rhythm of maintaining software.
Learning a big code base
Diving into a brand new project feels a lot like looking over a deep murky body of water. You are not quite sure what to expect, or where to start. That’s the feeling we all get. Every single developer first looks over a code base with a sense of helplessness. Imposter syndrome or not, the more you work in a code base, or section of a large code base, the more familiar you are with how the larger picture works. You may feel you are not quite skilled enough yet, however developing an understanding of the entire code base starts by understanding a single function.
Large companies actively seek open source contributors. to many managers, experience working with open source project is a great look for a resume. This establishes peer-reviewed skill in a certain language or topic. I have also had career opportunities open up because of certain projects I have worked with. Open source projects can be a great way to garner not only experience but resume bullet points as well.
While creating pull requests, your code will be reviewed and you might be asked for implementation changes. Rather than turn away, use these to better develop your skill in a specific language. Perhaps there was a much better way to implement a certain feature or a package in a standard library that does what your function seeks to do. Engaging with the open source community is one of the best ways to develop yourself as a developer. You will work with developers who have a lot of experience maintaining large projects, which will offer insight you may not have been able to see before.
A better understanding of Docker
I had always thought Docker was some cool tech but didn’t really deploy it until I started contributing. After I started seeing some more niche use cases thanks to issue tickets and bugs, I started to deploy docker in my own tech stack. Having already studied the code base, I was familiar with how things worked underneath Docker. This gave me a better understanding of not only how Docker is used, but why certain limitations exist.
You can often find documentation edits, as well as beginner-friendly edits, tagged as issues in a repository. These will help you learn the contributor workflow, or how pull requests are typically handled. Many bigger projects will have contracts you are required to sign before contributing or other stipulations. Even as a seasoned developer, these beginner tags are great to work on to introduce yourself to the community, and learn the culture and workflow behind the project.
Not every pull request can be answered quickly. Often times a project has way too many to process. Use this time to implement tests in your code. Check the CI builder and see if your code fails any test units. Make sure your code is linted and formatted according to contributor guidelines. This will make the merge happen much more smoothly if maintainers can focus on the implementation rather than styling nuances of your pull request.