What should I do when I get stuck? I come from the software engineering background. My main problem with math materials online is how dense and unforgiving those usually are. I often read a math article and get what the author is trying to say, up until a certain point where I have no idea how they arrived from A to B. Sometimes I'm lucky and it clicks, but even then I think they could've been more empathetic to their reader and explain the same thing with multiple operations instead of combining them into a single one. It appears as if most of the authors think that their readers have the same context as they do.
I never have this kind of problem in software engineering. I can always find an answer to a question or a solution to a roadblock. In worst case I can run the code myself, debug it, see how it works, etc. You could probably do something similar in math, however sometimes it is not practical. Here's an example:

How did they arrive at this conclusion? The article is about Euclidean Algorithm, so why would I know about this property of numbers? If it's necessary to know this property, then how can I find the name of the property, so I could look around online for alternative and more accessible explanations? How can I verify it? Should I write a $200$-digit-number on paper to do that?
While writing this question I actually understood the first expression, but what if I didn't? A lot of times I just gave up on some problems because I couldn't wrap my head around it and didn't know how to find a solution or explanation, etc. I'd love to learn math but this process is super frustrating and breaks my motivation. How can I resolve those blockers on my own, so that I could be as fluent with it as I am with software engineering?
 A: In software engineering, suppose you run into an object, called inequality. You look at the main body of the code, and just see inequality.howManyDivisions() used at a key step.  The natural thing to do is look up that object method and see what is happening under the hood, or just accept that the method is doing what it claims to do.  
So it goes with math. Except, math is a thousands or tens-of-thousands of years old discipline, and looking up inequality.howManyDivisions() might mean reading a book on number theory, or something related to groups, or whatever.  Or you just accept that you can't know everything, and the referees presumably were experts who knew what was essential and commonly known in their intellectual community, and accept that it's probably true; maybe even ask a colleague who does that kind of thing. There a trick used often in my field that looks like a typo, and people who are unfamiliar are always pleasantly surprised when they get an explanation, not just because it's useful but because it's so simple once you know how it's done. There's a lot of that going on.
A: I'll give a practical take on this:
The statement that you posted is just an example that the authors use to show why Euclid's algorithm is much more efficient than a naive gcd implementation. Since you are just interested in learning about Euclid's algorithm, if you don't understand this example, no harm is done in ignoring it. I adopt this strategy for most things I see in my math textbooks and focus only on the core theorems. If this piece of information is really crucial for solving problems, then I would come back and do a double take (try to learn the matter presented). Otherwise, out of most 800-page math texts, the core theorems are contained only in ~200 pages of subject matter. You need to pick up these theorems and apply them to solving your problems.
If you face a problem that you have to solve and are unable to comprehend the tools/strategies required to solve it, break it down!. Make a list of all the theorems that you need to solve said problem and then learn the theorems one by one. If you get stuck on a theorem, Math.SE is always there to help :). Once you're done with the theorems, you can go back to the problem and try to apply your learnings. Two things can happen at this stage:


*

*You solve the problem successfully. This is good and it means that you grasped the theorems

*You are unable to solve the problem. In this case, you need to pinpoint the location where you got stuck and revise the tools/theorems you are using in that location. Then, revert back to learning those theorems properly. Keep doing this and you'll eventually reach 1.


If you keep running into case 2, you need to be persistent. Persistence doesn't always mean tackling the problem head-on; sometimes it can also mean giving the problem a break. Stick with the problem, and you are bound to solve it. 

P.S: I wrote this explanation before noticing that you understood what the sentence is trying to say.

What the authors are trying to say is that every 200-digit number fits in the range 
$$10^{199} \le a \lt 10^{200} $$
This is because the smallest 200-digit number is $10^{199}$ (1 followed by 199 zeros) and the largest is $10^{200}-1$ (9 repeated 200 times). If you take a square root across the inequality, you get
$$3.16 \times 10^{99} \le \sqrt{a} < 10^{100}$$
since we have to find a list of divisors of $a$, in the worst case, we will have to divide $a$ by all the numbers less than $\sqrt{a}$. Thus, at most, we would have to perform $3.16 \times 10^{99} \approx 3 \times 10^{99}$ divisions. Even if we could do a billion divisions per second, it would take us $3 \times 10^{90}$ seconds or around $10^{82}$ years (!) to do this naively, without euclid's algorithm. That is all the sentence and associated paragraphs are trying to say.
A: As one of my favorite professors Hung-hsi Wu at Berkeley said, put the book down.  Perhaps try a different book.
A: Mathematical writing (at every level) expects more effort from the reader than other kinds of exposition, so you should expect to have to go slowly and work out many steps for yourself using some scratch paper. The goal is to see intuitively why things are true, so try to figure things out on your own before searching for explanations - it's much easier to follow a proof if you've already tried to solve the problem. For introductory-level topics, none of the proofs are particularly tricky - most of the work is just wrapping your head around the problem and "seeing it the right way".
In your example, if you didn't follow the first step, you might still understand that the 200-digit numbers are bounded, so stop and try to figure out what the bounds are. Write down examples with smaller numbers in place of 200 and try to find a pattern. Eventually you'll convince yourself that the statement you read is true.
A: In many cases  a general formula / statement can be better understood if you start with the simplest cases of application of that statement.    
The example you cite is oone of these cases.
If $a$ had just one decimal digit, then ..  (easy to catch the basis of the statement)
If $a$ had two digits , then ..( just a little more cpmplicated, but the path start to emerge)
if $a$ has $n$ digits ..
