What I Learned Contributing to Open-Source
One of the greatest challenges for someone starting out their journey into Software Development is getting experience. How do I get the job that requires experience if I can’t get a job because I lack experience? There are two possible ways of doing this: through an internship or by doing some volunteer work. In Software Development there is a special kind of volunteering that can be done without having any kind of experience, you can even lack the skills required! This is often known as contributing to an Open-Source project.
These projects and communities can provide a welcoming place for you to learn, experiment and gain experience. The length of the contribution can be variable, you can choose whether to make a big contribution that can take days to solve or make a smaller bug fix that can take you minutes to solve. You get to choose the investment you want to make. There are many valuable skills you can gain from contributing to open-source that will follow you into your career without having to make a huge investment in time.
In the past few weeks I made contributions to open-source projects. Some big like scikit-learn — Python module for machine learning, other more low profile like delta-chat —Email-based instant messaging for Desktop and AwesomeAdoption — A web application that helps users find pets to adopt around their area.
One step at a time
We tend to run before we can walk, many times this causes us to stumble and lose motivation along the way. That is why before starting with any type of modification to the code we must start with the first step: Understand the code thoroughly.
How to modify something you don’t understand how it works? How to add code to an existing database and ensure there are no conflicts? By having a solid understanding of existing code, you can easily build on top of it and avoid these kinds of problems.
When contributing to scikit-learn I had many problems developing solutions to the issues I was assigned because I didn’t understand fully what the classes and functions were doing, once I got the hang of it the process was smoother and easier.
Writing good code
My background originally being in Mechatronics Engineering, Software Development was a path that deviated from my training. The first language I learned to program was Python, but I had never written tests and I would regularly duplicate functions thinking the code would execute faster.
I was never focused on writing easily readable, structured, well-thought-out programs. I just wanted the code to work, and I was fine with writing code that only I could understand. Good programming practices were a foreign concept to me.
Open source requires contributors to hold themselves to a much higher standard however. Your code is read by thousands of people. Reviewers are often short on time, so it’s best to make their lives easy, or your code risks going out the window. This can make it a little daunting for first-time contributors, especially if their background is not in Computer Science.
When contributing to these projects I was tasked with making good, clean and reliable code that could be understand by anyone reading it. Also tests must be implemented to ensure that the functionality developed works in the correct manner, and to enable future contributors to make sure it will continue to stay that way after their modifications.
Taking feedback
Not to put it too lightly, but feedback is great. Without feedback we keep making the same mistakes. Without feedback we can’t learn and grow and evolve. It’s one of the keys that makes free and open source collaboration work. Unfortunately, most of us have a hard time receiving feedback, let alone accepting it. We identify too closely with our contribution, such that criticisms of it — no matter how valid — are taken personally and put us on the defensive.
Even if the person providing the feedback is unskilled at it, and their criticisms come across as personally directed, try not to take their comments in that way. Try to focus on the aspects of their feedback that relate directly to your contribution, then guide the feedback conversation toward these elements.
Above all, always assume good intent with all feedback. No matter how poorly a piece of feedback may be delivered, the person providing it is still giving you that gift of their knowledge and experience. You can use this feedback to grow into a more skilled contributor, then one day pay that gift forward as you provide feedback to others. This is part of the beneficial cycle that allows free and open source to grow. Remember, you are not your code.
