As you start to get comfortable with a language/toolset, build something real.
Even if it's small and simple and even if you or anyone else never really use it. Just make it something real that has to adhere to real world constraints.
A lot of how languages are structured and implemented, how tools are structured and presented, how documentation is written, how questions are asked and answered online, assumes a certain real world context. One of the best ways to start getting that context is to build something that someone could actually use.
You'll find that when you try to build something that could actually be used you'll start running into problems that you wouldn't see in an "introduction to ..." tutorial. Getting past those problems will force you to gain a real and practical understanding of the tools you're using. Also, hitting those problems will force you to read though and understanding the documentation for the tools you're using.
One of the things you'll hear over and over again is someone asking "what is the best way of doing ..." and someone else answering "well, it depends...". That "it depends" comes from a lack of context (i.e. there are a lot of correct ways of doing it and picking one depends on your context). It's great to know all of the ways of doing it, but building something real, giving your project that context, is how you can start narrowing down the choices behind "it depends".
A lot of concepts in programming don't really start making sense until you see them or the need for them in the wild, so start exploring the real world. This is not to say skip the intro tutorials. Definitely do them, but don't live only in the theoretic world forever. Pass between the theoretic and the actual worlds often so you can explore and understand both.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As you start to get comfortable with a language/toolset, build something real.
Even if it's small and simple and even if you or anyone else never really use it. Just make it something real that has to adhere to real world constraints.
A lot of how languages are structured and implemented, how tools are structured and presented, how documentation is written, how questions are asked and answered online, assumes a certain real world context. One of the best ways to start getting that context is to build something that someone could actually use.
You'll find that when you try to build something that could actually be used you'll start running into problems that you wouldn't see in an "introduction to ..." tutorial. Getting past those problems will force you to gain a real and practical understanding of the tools you're using. Also, hitting those problems will force you to read though and understanding the documentation for the tools you're using.
One of the things you'll hear over and over again is someone asking "what is the best way of doing ..." and someone else answering "well, it depends...". That "it depends" comes from a lack of context (i.e. there are a lot of correct ways of doing it and picking one depends on your context). It's great to know all of the ways of doing it, but building something real, giving your project that context, is how you can start narrowing down the choices behind "it depends".
A lot of concepts in programming don't really start making sense until you see them or the need for them in the wild, so start exploring the real world. This is not to say skip the intro tutorials. Definitely do them, but don't live only in the theoretic world forever. Pass between the theoretic and the actual worlds often so you can explore and understand both.