So I've come to the point where I've wanted some to see some features on the software I regularly use and I feel confident enough that I can pull it off. However, once I start getting into it, it all becomes so overwhelming that it's hard to get anything done.
For instance, on more than one occasion I had trouble getting the projects to build on my machine (eg., unsupported OS, lack of documentation, etc.) and it left me unable to write a single line of code making the experience frustrating from all the time wasted that I had to move on.
Other times, I recognize some the patterns and get the general gist of some snippets, but the overall code seems so convoluted to me that I don't even know where to start to analyze a solution, even though if it'd probably take ten lines to implement.
For context, I've been more of a hobbyist programmer for the great majority of my life with a bit of schooling. I do have various finished apps under my belt so I'm definitely not new. But I have no reference for how long a feature should take to implement in someone else's code for the average Joe who does this for a living.
So I'm left wondering: What advice do you have that could make this all more accessible to someone like me? Do you have a general strategy to get started? How long does it take you from start to finish? And if you run into issues, where do you seek help without nagging the devs about their code who may take too long to respond to be of use?
Many thanks for the feedback in advance!
Looking back on my career, submitting your first merge/pull request can take anywhere from a few hours to several weeks (we're talking about 8+ hour work days). And that's at companies that have an onboarding process and coworkers you can ask for help and explanations about the code base, architecture etc.
Getting into someone else's code (this may include your past self) is almost never easy and often feels convoluted, because it's very difficult to see the context that existed at the time when the code was written. And by context I mean everything that influenced the decision to write lines the way they were written, including undocumented discussions, necessary but non-obvious workarounds, understanding of the problem and solution space by the dev, general state of mind of the person writing the code and more.
Don't beat yourself up because you couldn't contribute in just a few hours.
I would first reach out to the devs on IRC/Discord/Matrix and express interest to contribute and see how they react. You don't know if they would even accept your PR, so I wouldn't do too much work upfront.
Then, when they are open to work with you, find out if they are willing to help you ease into the code. What files should you study to implement the changes that you've discussed earlier, any considerations that are not obvious, is there legacy code that you shouldn't touch etc.
It's important to keep in mind that (collaborative) software development is more than just being able to write code. And a lot of the surrounding work is not very glamorous or fun.
I hope that helps and wish you good luck! ๐ค