Read
Examine this poem. We'll get back to it in a bit, but for now, keep it in mind:
< > ! * ' ' #
^ " ` $ $ -
! * = @ $ _
% * < > ~ # 4
& [ ] . . /
| { , , SYSTEM HALTED
With computer code as a primarily visual language, reading is going to be one of the two primary actions associated with it. One of the best ways to get good at language skills is to read language. Aloud, preferably, for early learners, so that the pronunciations and the symbols meld together properly. This is easier to do, perhaps, with the languages we are used to hearing the sounds and syntaxes of than the ones we are not.
Imagine, for a second, having to discover all the syntax of a language, having perhaps been taught "Hello World" in that language. For some languages, like C++, Hello World has a lot of information about the context of the program baked into the program itself.
// my first program in C++
#include <iostream>
int main()
{
std::cout << "Hello World!";
}
(https://cplusplus.com/doc/tutorial/program_structure/)
For other languages, there's not so much context at all.
puts "Hello, world!" # Print out "Hello World!"
Trying to determine what a language can do without having previous examples of the language to build on is going to be a nightmare.
Studying other (hopefully well-documented and commented) code allows us to not only expand our knowledge of the words of code, but also allows us to see how they get put together into intelligible statements and routines, and how those routines then become functions, and then programs past that, assuming someone isn't deliberately obfuscating something in the name of security or complexity. Similarly, early learners learn letters first and their attendant sounds, then use those letters to make words, which then become sentences, paragraphs, and full works.
It's best, of course, to start with beginning readers and simple works that have only a few words and fairly simple grammar and syntax, and that behave in regular ways, and then to add in the weird cases, the more complex operations, and the things that require an understanding of how other languages work later. (Because loanwords and their attendant pronunciations and meanings are a thing in any language, despite the attempts of every Ministry of Language to prevent them from happening.) So, yes, start with The Cat in the Hat, Green Eggs and Ham, and Hamster Huey and the Gooey Kablooie before progressing on to the Gawain-poet, Dante, and Chaucer.
In the realm of learning how software works, tutorials and documentation are the way that people can read about what software does and works, whether those documents are in the program as help files or elsewhere, like web tutorials and demonstration videos. These tools, especially videos, make it easier to see how the flow of software works, rather than having to write up a set of steps / inputs and describe the outputs that would come from that. They have their own problems, of course - if you've ever been a language learner in the company of people who are fluent and speaking at rapid speeds, then you understand why video tutorials are sometimes not very helpful, either, even if you can stop them, rewind them, and play them at whatever fraction of full speed you need to be able to keep up with the keyboarding and explanations going on.
Starting at such a simple-seeming level is frustrating to those who are learning a second or more language, because the fluency they have achieved in one language only helps them show and understand the lack of fluency they have in the other language(s). Some of this can be alleviated with peer mentoring and conversation.
Let's get back to the poem we started at the beginning of this section:
< > ! * ' ' #
Waka waka bang splat tick tick hash,
^ " ` $ $ -
Caret quote back-tick dollar dollar dash,
! * = @ $ _
Bang splat equal at dollar underscore,
% * < > ~ # 4
Percent splat waka waka tilde number four,
& [ ] . . /
Ampersand bracket bracket dot dot slash,
| { , , SYSTEM HALTED
Vertical-bar curly-bracket comma comma CRASH.
Bemmer and Korese, May/June 1990 issue of Infocus magazine
Learning a second language also introduces the problem of faux amis. ("False friends", literally). Faux amis are false cognates, words that look and sound similar between two languages but have entirely different meanings. For example, you buy books in bookstores and borrow them in libraries in an English-speaking country, but you buy books in librairies and borrow them from bibilotheques in French-speaking ones. The same sorts of things happen in programming languages. Python lists and Ruby lists might be the same, but Ruby hashes are not Python dictionaries, even if they look the same.
I often get tripped up between variable assignment (=) and the equals comparison operator (==), because when I learned my grade school math, = meant ==, and nobody actually taught me in high school algebra that when I did things like solving for x, what I ended up with was an assignment statement instead of a comparison.
The poem Waka Waka demonstrates that sometimes language symbols have different meanings - the hash mark (#) appears twice in the poem, but the first time, it's a hash, and the second time, it's a number sign. When it comes to programming, Not to mention some of the additional fun possible in Ruby, where someone could add an additional line of code to the poem before the last one:
<=> => << >> HashWithIndifferentAccess flying saucer hashrocket shovel shovel Mash
which are all conveniently operations and items that either use double symbols or CamelCase to produce their desired effects. Every computer language is weird, sometimes more so than the conventional language it derives from, so any and all tricks that you can use to remember and do things right are fair game.
Learning a second (or first) of anything often results in a lot of frustration, especially when there's a gap in between knowledge of one and knowledge of the second. Really, there's not too much that can be done about that frustration than...