I program in C and python, and even good first issue problems seem like I have to be Dennis Ritchie himself to solve them. How do I know when I’m ready to solve and commit to projects?

  • grandel
    link
    fedilink
    arrow-up
    60
    ·
    1 year ago

    It may not be the best approach but i usually just open a PR or create an issue and offer a PR.

    They usually let me know if it’s lacking or my approach is wrong.

    There’s no shame in not knowing something.

  • macniel@feddit.de
    link
    fedilink
    arrow-up
    29
    ·
    1 year ago

    You know that you are good enough at coding when your Merge/Pull Request gets approved. So get on it!

    • heeplr@feddit.de
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      Rather if they get merged without edits.

      I’ve seen even minor changes without flawed technique or style being discussed and changed for days before getting merged.

      But it’s also an excellent way to learn from pros. If the PR is worth it, they will spend the time for review and work with you until you fixed everything.

      • Anticorp
        link
        fedilink
        English
        arrow-up
        9
        ·
        1 year ago

        Eh, excellent code still gets discussed. Your approach might be unique and they haven’t thought of it before. Or you may have perfectly suitable code, but it doesn’t consider other parts of the project that you’re not familiar with. Discussion isn’t an indication of bad code, unless the only thing being discussed are mistakes.

        • macniel@feddit.de
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          That would be amazing, when your submission cause to improve the entire code base quality!

  • knokelmaat@beehaw.org
    link
    fedilink
    arrow-up
    26
    ·
    1 year ago

    Just look at issues in software you use.

    Start with a simple project. Clone the code and try to build it (this is already a very big step in software development, so don’t be angry with yourself if it takes a while). Poke around in the code, change some stuff, get a feel for the architecture. Then see if there is an issue that you could help with. Ask questions on the projects communication channel(s). Most developers will be kind if you ask for help or advice.

    Good luck! 🤞

  • Buttons@programming.dev
    link
    fedilink
    English
    arrow-up
    19
    ·
    edit-2
    1 year ago

    There are (roughly) two types of projects:

    1. Projects that have coding standards that are documented. If you want to contribute to one of these projects then read the coding documentation and follow it. People will help you write code that fits the standards.

    2. Projects that don’t have coding standards. When you look at such a project you’ll see endless layers of shitty hacks that mostly work, sometimes. Add your own shitty hack to the pile and as long as everything still mostly works, you’re good.

    • star_nova@beehaw.org
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 year ago

      Seconding this and wanted to add:

      It’s more or less the repo owner’s job to keep the codebase organized. So if they created a set of standards, follow them. If not, submit as clean a PR as you can.

    • jarfil@beehaw.org
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      Even without clearly defined coding standards, always try to match the style of whatever code you’re contributing to. It may make your code stand out less, but will make it easier for everyone, even your future self.

  • Anticorp
    link
    fedilink
    English
    arrow-up
    11
    ·
    1 year ago

    As soon as you can solve an issue! I found a bug in a Yelp WordPress plugin back when I barely knew any PHP and figured out how to fix it, because I needed that plugin to get paid for the project I was working on. I submitted a pull request and they accepted it! That’s the first contribution I ever made to a corporate project. The people in charge of the repository will give you feedback if they want things changed, and can provide a lot of guidance. Just start committing and you’ll learn a lot.

  • RandoCalrandian@kbin.social
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    1 year ago

    Every problem looks impossible until you see the solution, and then it was obvious the whole time.

    The feeling never goes away, instead you do what some other commenters have suggested:

    • pick a project
    • get it building locally so you can fix something
    • pick a bug from the list
    • get to work. Understanding what to write means understanding what the solution is, which means understanding the problem and the scope of it, what parts you can fix and what not. This process is more akin to going on a nature hike than painting the view, but people always seem to assume coding is more like the latter.

    Tbh, you will likely be able to eventually solve any bug, given time and effort. Reaching out to discord groups in the language or product domain when you have questions will speed the process up.

    • Pierre@beehaw.org
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      When choosing a bug, if you start with one that is possible to reproduce, it might help following the instructions to reproduce it while debugging the app and observe what happens. This can be a way to start understanding how it all runs. Bugs without context or hard to reproduce are usually more complicated and you might need a better knowledge of the code to have an idea of where to look.

  • jarfil@beehaw.org
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    1 year ago

    How do I know when I’m ready to solve and commit to projects?

    There are a few ways:

    1. You notice a problem, write some code, compile/run it, and it works. 🎉
    2. Download a project with some tests, set up the testing environment, do as per point 1, run the tests and keep fixing your code until they don’t fail anymore. 🎉
    3. Do as per point 1, submit the PR… and many people will tell you whether you’ve missed something. Depending on their character, they might be helpful, ignore you, or rarely be assholes. YMMV. 🎭
    4. Fork the project. Now you’re in control, so proceed as per point 1. To make your life easier, write some tests, set up a testing environment, make it easy for others to replicate, document stuff, both for you and for others, describe the general architecture to have a high level view of it, and so on. 🎉
  • averyminya@beehaw.org
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    I have a feeling there are people far worse at coding than you being far more active in projects. If you don’t start, will you ever?

  • Sha'ul@lemmy.ca
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    1 year ago

    Since you’re asking, you’re definitely not ready. Learn a projects formatting style for the code, work on open issue, submit patches, listen to all critiques and criticism.

    Submit and the others will say when you’re good. If you want to learn code correctness and proper security of code, study and go through OpenBSD’s code. You could read the code for openNTPd and the code for OpenSSH, then move on to reading kernal code for OpenBSD.

  • bet@lemm.ee
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    In the sense I think you’re asking, never: contributing a fix or an improvement is never a one-and-done, fire it off and forget it edit. Each contribution is a request to open a dialog. Implicit in each pull request are multiple questions, perhaps including “is this a good idea”, and “do you like this attempt to do it”.

    If the project maintainer who reviews your PR doesn’t like it, they can expend the effort to try to explain why, and teach you. So try to make their job easier, by opening with a clear explanation of why you’re doing it, and if what you did involved design decisions, why you chose as you did.