I have been a hobbyist programmer for quite some years and have a few smaller projects under my belt: mostly smaller GUI applications that have a few classes at maximum, make use of one or two external libraries and are very thoroughly documented and commented.
Since I love the free software movement and philosophy, I wanted to start contributing to projects I like and help them out.
The thing is, the jump from “hobbyist” to “being able to understand super-efficient compact established repos”… seems to be very hard?
Like, looking into some of these projects, I see dozens upon dozens of classes, header files, with most of them being totally oblique to me. They use syntactic constructs I cannot decipher very well because they have been optimized to irrecognizability, sometimes I cannot even find the starting point of a program properly.
The code bases are decades old, use half the obscure compiler and language features, and the maintainers seem to be intimately familiar with everything to the point where I don’t even know what’s what or where to start. My projects were usually like four source files or so, not massive repositories with hundreds of scattered files, external configurations, edge cases, factories of factories, and so on.
If I want to change a simple thing like a placement of a button or - god knows! - introduce a new feature, I would not even remotely know where to start.
Is it just an extreme difficulty spike at this point that I have to trial-and-error through, or am I doing anything wrong?
If there is something you see that is missing - particularly documentation - then perhaps that is an excellent place to start? The older devs may have just been waiting for someone like you to come along and could be ecstatic to hear that you want to make that. Maybe they used/continue to work together in a company or are old friends or sth and did not need that, so you could break the project wide open, making it easier for everyone who comes after you, possibly also changing the very culture of the project and encouraging the more senior devs to write documentation as well, as they make new things or solidify an existing foundation before extending into new territory. And there are so many forms of documentation - Pre/Post conditions, listing dependencies/interactions, plus overall description of assumptions made - that even if some of that exists, the project could perhaps still benefit from adding more, especially from the perspective of a newer team member.
Do not neglect the “people” side of things - maybe try to connect to some of the more senior devs on Discord or wherever they are first? Like on the plus side they could give you pointers, tell you what you can ignore, send you links to documentation that would have been hard to find on your own, etc. Seriously: imagine spending 6 months writing documentation for an enormously-complicated aspect of the code (like a major, central class + all of its dependencies), only to see the entire thing discarded & replaced, and you find out only then that it was always intended that way from the start. (still not a deal-breaker, b/c most of that “6 months” would be you learning stuff and getting familiar with generalities, so not entirely wasted, yet not entirely productive either if you could have been told to have picked a different entry point into the project) While on the minus side, if you see that they are just flat-out idiots, then you can abandon the project now and move on - that is a thing that can happen, and it is better to know ASAP than to only really be confronted by that a year or two in.:-(
Perhaps also consider your “fit” for the specific project. If you are good at many things, but not at the specific things involved there, then there will be a greater cost for you to work in that area, and you will spend more time “learning” and less time “contributing” (plus, how much time will people be willing to devote to helping you do the former, when you have done none of the latter yet?). Ngl, depending on the number and styles of languages involved - e.g. a script that calls an optimized C++ library that then feeds data into making an SQL query that uses a REGEXP into a database that has literally zero documentation anywhere… and so on - and your prior amount of experience with each of them, could take a good several YEARS to catch up, as only a side-project. Even if your expertise could help them - e.g. if you are great at UI/UX while the senior devs are more full-stack but almost exclusively focused on the back-end side - there is still the matter of you needing a way to deliver your contributions to them, i.e. understanding the existing codebase enough to be able to modify it to implement your ideas.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Some thoughts:
If there is something you see that is missing - particularly documentation - then perhaps that is an excellent place to start? The older devs may have just been waiting for someone like you to come along and could be ecstatic to hear that you want to make that. Maybe they used/continue to work together in a company or are old friends or sth and did not need that, so you could break the project wide open, making it easier for everyone who comes after you, possibly also changing the very culture of the project and encouraging the more senior devs to write documentation as well, as they make new things or solidify an existing foundation before extending into new territory. And there are so many forms of documentation - Pre/Post conditions, listing dependencies/interactions, plus overall description of assumptions made - that even if some of that exists, the project could perhaps still benefit from adding more, especially from the perspective of a newer team member.
Do not neglect the “people” side of things - maybe try to connect to some of the more senior devs on Discord or wherever they are first? Like on the plus side they could give you pointers, tell you what you can ignore, send you links to documentation that would have been hard to find on your own, etc. Seriously: imagine spending 6 months writing documentation for an enormously-complicated aspect of the code (like a major, central class + all of its dependencies), only to see the entire thing discarded & replaced, and you find out only then that it was always intended that way from the start. (still not a deal-breaker, b/c most of that “6 months” would be you learning stuff and getting familiar with generalities, so not entirely wasted, yet not entirely productive either if you could have been told to have picked a different entry point into the project) While on the minus side, if you see that they are just flat-out idiots, then you can abandon the project now and move on - that is a thing that can happen, and it is better to know ASAP than to only really be confronted by that a year or two in.:-(
Perhaps also consider your “fit” for the specific project. If you are good at many things, but not at the specific things involved there, then there will be a greater cost for you to work in that area, and you will spend more time “learning” and less time “contributing” (plus, how much time will people be willing to devote to helping you do the former, when you have done none of the latter yet?). Ngl, depending on the number and styles of languages involved - e.g. a script that calls an optimized C++ library that then feeds data into making an SQL query that uses a REGEXP into a database that has literally zero documentation anywhere… and so on - and your prior amount of experience with each of them, could take a good several YEARS to catch up, as only a side-project. Even if your expertise could help them - e.g. if you are great at UI/UX while the senior devs are more full-stack but almost exclusively focused on the back-end side - there is still the matter of you needing a way to deliver your contributions to them, i.e. understanding the existing codebase enough to be able to modify it to implement your ideas.
I hope this helps!:-)