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
    link
    fedilink
    English
    arrow-up
    7
    ·
    7 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
      link
      fedilink
      arrow-up
      2
      ·
      7 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
        link
        fedilink
        English
        arrow-up
        3
        ·
        7 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.