I would like to code for a living and to contribute to open source projects and things, but my coding skills are absolute shit after taking online courses and watching video tutorials. How can I learn to code for real?

What I would like to learn is algorithms, web development (“full stack”), how layouts work (both in like kotlin compose and HTML) and how to read other peoples code. Maybe thats more than I can chew, but its probably good for me to try out many things before getting settled on one.

Now I have been coding for a while already (~ 4 years), but I kind of feel like I need more guidance to be able to actually create code that works as intended intentionally, and not through trial and error / stack overflow. As for what level i am at, CS50 is probably my only qualification, I have played around with APIs (I.E. making discord bots), and made some html “apps” (horribly made, but things like the “genius” game and a calculator) and “prototype” react websites (as in, really bare bones, barely working).

I do plan on taking CS or something similar, but i’m not yet in college, and I would like to have a good head start before getting there.

Sorry for my bad English, and any help is appreciated.

  • gjoel
    link
    fedilink
    arrow-up
    14
    ·
    2 days ago

    To me, what sets apart good coders from mediocre ones is one thing: understanding why we do things. Don’t just implement the thing because that’s the task. Understand why it’s required and your implementation will be better. Don’t blindly follow best practices. Understand why they are best practices and when they apply. Understand what’s going on rather than just do what you’re told (but probably also do what you’re told if you want to keep your job).

    I know people who have been at it for many years and they don’t understand why we do things this or that way, they just know that’s how we should do it.

    • Nibodhika@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      1 day ago

      This, this is it, right here. I can’t tell you the amount of times I wanted to smash a coworker head against the table because they were doing stuff the way it was “supposed” to be done without understanding the reason. For example at one job I worked doing rebases on git was prohibited, everyone knew it was a rule, everyone respected it, I kept asking why but no one had an answer, until at one point I was chatting with a senior architect and I asked him and he said “oh, it’s not prohibited, it’s just that someone messed up a repo trying to do a rebase once so we told them not to rebase unless you knew what you were doing”. And just like that there were thousands of other things that made me realize that most programmers just accept things as they are instead of trying to understand why, which causes several problems, the most common one being the XY problem.

      • gjoel
        link
        fedilink
        arrow-up
        3
        ·
        1 day ago

        I had the exact same experience when starting a new job. The team had very strict rules that absolutely could not be broken. When I finally asked an architect he said the same thing: it’s just a general guideline, but of course if it makes more sense to deviate, then by all means.

        They fostered this culture because they mostly had junior programmers, but they never evolved beyond that because they were taught “good code” but never learned why it’s good code.

    • iamtherealwalrus@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      2 days ago

      Adding to your advice: RTFM. I have been a professional developer for more than 20 years and the number of people i have worked with, who bothered to read the manual, can be counted on one hand. So many bugs can be avoided if people bothered to read the manual for whatever software/SDK they are using.

      • DefrostedTuna@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        2 days ago

        Jeezus, you’re not kidding. I’ve been in the industry for more than a decade. Everything I write I make sure is covered by documentation in detail. Never know when I’ll be unavailable to address something that pops up. I get pings daily with people asking me how to do X with Y system, even on vacations. I’ve gotten into the habit of just sending them a link to the documentation that explains what they’re looking for. I get not wanting to sort through piles of documentation for a small thing, but holy hell it gets exhausting after a while. If people would even skim the manuals they’d have an idea of what and where to find stuff. Don’t know why I even bother half the time if nobody is going to read it.