I’m really enthusiastic about anything involved with Unix/Unix-like operating systems and their ecosystems (Mostly Linux and a bit of BSD variations). I also know a couple of programming languages including C, C++23 and OCaml. But other than doing a couple of tiny projects mainly to practice my programming skills in the languages mentioned above, most of my experience is theoretical and it comes from reading books, blogs and watching conferences.

I’m interested in gaining “actual” experience by doing systems programming related projects but I’m not sure how to get started. How do I decide on which topic to choose? A topic which would not be too overwhelming and actually achievable? And how do I gain the background knowledge needed to implement a project without ending up copying and pasting everything from existing implementations?

Thank you!

  • fuzzzerd@programming.dev
    link
    fedilink
    arrow-up
    11
    arrow-down
    1
    ·
    7 months ago

    The reality is that you can’t. So accept that going in and realize your learning will be iterative.

    You’ll be overwhelmed, that’s OK. Copy paste code until you get something working. Here’s the key. At that point stop, go back and understand the code you copied, why it works, and then try to rewrite it differently now that you know what worked.

    Metaphor for writing. Start with a quote, then paraphrase it. Do that enough and you’ll start to be able to adlib and come up with your own solutions.

    • Ephera
      link
      fedilink
      arrow-up
      5
      ·
      7 months ago

      Personally, rather than copy-pasting code, I like to actually copy it by typing it out, especially if I’m still learning the syntax of a new language. It just makes you read the code much more attentively than glancing over it after it’s already written.

      • fuzzzerd@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        7 months ago

        Absolutely. That’s a fantastic way to do the “copy/paste” I definitely think it helps when learning new language.

    • Hammerheart@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      I learned something very valuable relatively early in learning how to program: sometimes, if you do things you don’t understand enough, the understanding will come as a byproduct of just doing the thing.

      I had been stuck in a “i must understand the fundamental nature of everything i do before i do it” mindset, so this was quite revelatory to me.

  • 4wd@programming.dev
    link
    fedilink
    arrow-up
    5
    ·
    7 months ago

    Some “pro” guys on YT will probably point you to https://github.com/codecrafters-io/build-your-own-x and https://github.com/practical-tutorials/project-based-learning. But…

    I don’t recommend reinventing the wheel if you want to gain REAL development skills. Development is really about achieving your goal using existing (and preferably popular) solutions.

    It makes no sense to write any system-level projects from scratch in 2024 if projects with a similar purpose already exist. Try using them as a regular user. Maybe you will find features that you would like to fix or add.

    • Ephera
      link
      fedilink
      arrow-up
      3
      ·
      7 months ago

      I always found it overly prohibitive, to not reinvent the wheel, because there’s a lot of wheels already out there. If I have an idea for a project, I do make sure to not look up any existing solutions, because that would kill my motivation immediately.

      I wouldn’t follow a tutorial either, though, since figuring out how to do it, that’s half the learning process.

    • ericjmorey@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      7 months ago

      If your goal is to complete a task, then using what exists is typically the best path. But that’s not the only goal to strive for.

  • Ephera
    link
    fedilink
    arrow-up
    5
    ·
    7 months ago

    Personal opinion is all of them.

    Yes, there’s some skills which you will only encounter, if you’re actively building up a larger project. But you can’t just stumble into a larger project and learn all of those, you do need to actually (help to) build it from the start. And that takes a lot of time.

    Having a larger project going on, on which you’re motivated to continue building every so often, that’s really good. But you’ll need to do some smaller projects every so often, too, to keep up motivation and give yourself a chance to start fresh and maybe do things differently.

    In particular, small projects also allow you to spend a completely unreasonable amount of time on some specific topic, because the scale of it won’t be as big of a multiplier. And adding those topics together, you will have a lot of the knowledge for a larger project.

    Particular topics, which you should spend a completely unreasonable amount of time on:

    • unit tests, integration tests
    • error handling, logging, monitoring
    • a build system, CI/CD
    • refactoring, structuring a larger code base, multi-project builds
    • TLS, authentication/authorization

    (Do not try to do these all at once. Pick out one or two new ones per project.)

  • Lmaydev@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    7 months ago

    Making any polished/releasable project will teach you a lot.

    To paraphrase it takes 20% of your time to do the fun 80% coding stuff and of your 80% time to do that last 20% polish etc.

    You can look up anything you need as you go. Start simple and get core features going. Then add more once the core is totally finished.

    Choose literally anything that interests you.