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!

  • wewbull@feddit.ukEnglish
    1·
    6 months ago

    Honestly, I run and gun. I make the change I want, and submit a merge request. I then move on. It’s then up to the maintainer to accept or reject it.

    I’m not going to debate it. I’m not going to rework it over the course of months to make it perfect in the maintainer’s eyes. I don’t care enough about it. I’ve solved my problem. I’m just sharing it for others.

    The things I submit are normally big fixes with the smallest possible code change, not refactorings to solve an underlying problem.

    • CameronDev@programming.dev
      0·
      6 months ago

      Out of curiousity, whats your success rate?

      I dont think there is anything wrong with that, as long as you are setting the expectations right. In some ways, it takes the load off the maintainer, because they dont necessarily have to “fix” your code, they can just rewrite from scratch using your code as inspiration.

      • wewbull@feddit.ukEnglish
        1·
        6 months ago

        Not high. It tends to result in one of a few things.

        1. They take the fix as offered. Probably it’s a smaller quiet project where the number of PRs is small. That, or very well run.

        2. It remains forever open and gets lost in the masses of other out of date PRs. Maybe a bot comes along and closes it as stale. Biggest group, and these ones just tell me that I’ve got very little chance of getting the maintainer’s attention. I can see that 100s of others have experienced the same fate.

        3. Somebody else finds it useful and adopts it, fighting for it to go in. Sometimes that someone is the maintainer. As you say, it can be inspiration for a rewrite of my contribution. That’s fine by me. Whatever works.

        4. The maintainer makes a bunch of rework demands leading to rejection, or it gets rejected straight off. “My way or the highway” is always going to be highway. I offered a small piece of help, and if it’s not wanted I’ll happily go away.

        Maybe 20% get in, but it depends on so many things.

  • psycotica0@lemmy.ca
    1·
    6 months ago

    Some tips:

    • Unless the code is very small, or your feature is very big, try to put blinders on, and focus only on the code you absolutely need to to get your feature built. Use search tools to comb through the code to find the relevant methods while reading as little surrounding code as possible, tweak those methods to be different, and call that a first draft. If the maintainer wants the code refactored or differently arranged, they can help with that as part of the review process
    • Being unable to build sucks, it really does. But if the software is released for your platform, it means someone out there is able to build it. And these days that someone is often an automated build tool that runs per release. See if you can figure out how this tool works. What build steps it uses, what environment it runs in, etc. If you can’t figure that out, try contacting the person who releases the builds
    • If the software is in apt (if you’re on a Debian-based system), you can use apt build-dep, apt source, and debuild to try and recreate the native apt build process. These tools will give you the source that built the system package, and its dependencies, and allow you to build a deb yourself out of it. Test the build to make sure it’s working as-is. If it is, and if the software’s dependencies haven’t changed too much, you can even use apt to fetch the old version that’s in the repos, update the code to reflect the upstream release, and then test the build there to see if it still builds. If so, now you have something you can start working off.
    • If you aren’t on an apt system, but do have a package manager, I assume there’s an equivalent to the workflow mentioned above
    • If your change is subtle enough that you think it’s pretty low-risk, you could just edit the code even though you can’t build it. This might be sufficient for bug-fixes where you just need to check something is greater than zero, or features where you pass a true instead of a false in certain conditions or something. You should probably mention this in your PR / MR / Patch so the reviewer knows to test building it before merging.
    • This one is a bit wild, but let’s say you’re on a Mac or Windows machine, and the build instructions only work for Linux. You can just run a virtual machine that’s got Ubuntu or something running on it, and use it as your build environment. These days you can probably be in a simpler situation with Docker or something more lightweight, but as a worst-case scenario, a full virtual machine is there for you if you need it
    • And finally, if the tool isn’t a crazy popular or busy tool, it’s possible the maintainer or other people in the community are more approachable than you think. If they are looking for contributions, then getting a willing contributor’s build environment setup is a benefit to the project. Improving their build docs helps not just you, but potential future contributors as well. A project will usually be more helpful towards someone who says “I’m trying to build this feature, but I’m running into trouble” compared to someone saying “why doesn’t your tool do X”. You may need to be a bit patient, they’re probably doing this on volunteer hours, but they might be happy to help you get your stuff sorted out

    Good luck out there, and try not to be discouraged!