How do people learn how to do anything related to coding on their own

If you're learning from someone else's first principles and it's not working for you, which is really common, try the break-fix opportunistic approach instead. Take something already built for purpose and use it until it breaks, then fix it. Always use every workaround possible in the meantime. Work around whatever you can't fix; even if you think you'll end up with a pile of workarounds, it will be a really well understood pile which is quite different.

This way you'll still get to first principles eventually as you understand the system more. You'll have infinite chances to design your own as your knowledge and experience increase. But some people have better results working in this way instead of starting from first principles. They are sometimes known as results-oriented personalities as opposed to process-oriented. In that they work backward from the needed result (which may be even completely improvised) as opposed by working forward with their own organizational ground-up process.

See you in a few years, when you you'll ask for advise as there aren't jobs for people whose stack is arm, *bsd, sqlite/postgres/redis, cl/elixir/go.

I spent one summer in high school just to learn how to upload files via FTP. I would go once a week to an internet cafe (no internet at home) and I'd try to use shareware software(FileZilla did not exist yet) or upload files with Internet Explorer to some free hosting service, but nothing would work. When school started, a CS teacher overheard me asking a colleague about uploading files and recommended I use Total Commander's built-in FTP feature. From that day on, I knew how to upload files.

I honestly don't know what to recommend. I'd say use Linux because a lot of tutorials are doing that. But Linux might bring even more troubles, or you could be exchanging one set of problems for another. macOS might be a good compromise.

For me it was difficult learning how to use computers and how to program them. But I find it rewarding to solve problems and that gets me through the pain.

Here's what I'd recommend:

* If you could build anything, what would you build? Have a clear vision and make sure it excites you. It could be an app, it could be a game, it could be the next GPT-3, it could be a calculator. Whatever the case, this is your north star & what you should work towards

* Forget about tutorials, focus on your building vision

* Seriously, don't overthink it - just start building

* Start small. Break it down into layers and tackle each step as you get there (eg. first I will create a webpage, then I will figure out how to share it with my friend, then I will make the webpage do something, then I will make it look pretty, etc.)

* When you get stuck, Google the problem. Don't think anyone's judging you, literally ALL 100 million developers before you Googled "javascript how to add another item to the end of an array"

* If you get stuck, have the mentality that GIVEN ENOUGH TIME you will find a solution to the problem

* Programming is a creative endeavour. If you don't know how to move forward, step away and take a break. You'll likely come back with 100 more ideas to try

* Focus on your vision. Work towards building it. I promise in a few weeks you'll be amazed at what you've managed to build

But to go on a bit of a tangential rant about doing it "on our own":

I don't think many people do it on their own _really_. Most people eventually get to a point where their code is out in the world for feedback. Whether it is something they're getting reviews on at their job, or a personal GitHub account, or their blog.

I learned enough to hack stuff together through trial and error in a little bubble to start with, but then I started blogging and getting involved in the community of a framework I'd been using. I would post questions and try to contribute answers, and all of that expanded my knowledge (even answering a question usually involves learning).

Later, as a junior programmer, I was on a team that had a _very picky_ teammate. He'd point out every nitpick he could in code reviews. Things that might not necessarily "matter" in practice in _that_ particular scenario, but that were just not as efficient or well implemented as they could be. I put "matter" in quotes because my mindset is now: of course it matters. Knowing what tradeoffs I'm making and not getting complacent with quality always matters, as I learned from these reviews.

And when reviewing my code he always asked "Why" questions. Why did I chose to use this data type vs that one? Would a hashset be better here? Why did I go with a LINQ method? What iterations are involved in this, and why do we need it? Why is there a null check here, why would this ever be null (a harder question than one might think considering we were working in a huge, old, proprietary codebase)?

Every code review was a bunch of questions and improvements, and it was extremely useful. I learned to predict the kinds of questions he'd ask me and look for answers in advance, often finding better approaches in the process. And when he asked "Why" in the next review, I'd get to explain exactly why, and how other options were subpar in this case.

I'd credit him with a very big chunk of my development as a programmer: mostly learning about the importance of why I'm doing something this way vs another way, digging into internals, deciding if the performance tradeoffs of my approach are worth it (and _knowing_ the performance tradeoffs), and paying attention to details.

I'm technically what people refer to as "self taught", but I definitely didn't do it on my own.

The reason everything is so hard is because technology we use today is inherited from decades of prior artwork and can be at times intolerable even to "pros". My benefactor went on and on about the meaning behind what makes a "hacker" exceptional compared myself. This is hard to communicate or understand but can be realized, after thousands of hours of struggle.

(My second benefactor told me something recently) I had a hard time realizing, in regard to returning to university, after a decade in the industry. He said, You have to interact, books aren't enough. Since he was a polymath professor, I could not argue, simply because my strategy thus far in this regard, objectively wasn't working out, irregardless if I was capable or not. I feel as though this is true because it's hard to rival yourself, you must see others (such as on HN) do better and take that as a challenge.

Trust me, if you have potential, simply make yourself known wherever you wish to be. Keep making mistakes.

It may be harder than when I got started, since software back then tended to be more self-contained. But if you can install Python/IDLE and get it to run, that should be enough to start playing with code.

As for computer science (algorithms etc.) it helps to have some reasonable mathematical maturity, so you can understand things like big-O notation intuitively. I'm not sure if that's what you were asking though.

You keep at it, understand and remember some simple things at first, read man pages/google for others, and eventually you make mental patterns and learn to understand what's going on, even when it's not working "as it should".

I actually take pride in being mostly self-learned concerning computing. "Only the self-learned is learned. Others are taught." Erno Paasilinna.

1) started drag&drop with simple logic using Delphi. It was fun but eventually ran out of ideas for problems to be solved and moved on to 3D modelling and then life happened.

2) Some years later, started watching some MIT videos where some math professor was teaching python via mathematical problems. It was awfully boring,so I stopped shortly after.

3) Got a job that eventually evolved into doing technical things. Got bored and started learning basic programming so O could solve more complex business problems. O was hooked. Automations, efficiency going up,etc. It all started from really basic database triggers and then gradually was getting more complex with integrations and etc.

I've also tried many tutorials,in the same way you did. For instance, recently I've tried Erlang. The language is beautiful but got stuck for hours in like step 3 because of some odd database related issues. It took much longer than I thought it will. The same with JAVA and Maven,etc. I think getting stuck on the infrastructure as opposed on the actual programming problems is very often problem. It's super frustrating, but what it does eventually it requires you to stop and really understand what os going on with that command line, some DB connection or a particular version. It's slow, painful process. If you manage to go through it,many many things become much easier afterwards.

I recommend starting with Hello World. From there add code and methods to that working tutorial and see how far you can go. When comfortable, start making your own app from scratch. Reading + copy/pasting people's code will be a large part of learning a new language.

For tutorials that add complex features, be aware that they have more advanced error situations which require more experience to get out of.