On 11/23/2018 at 6:54 AM, Lunari said:
I think I lose interest due to some things, such as certain algorithms, are way too difficult for me.
This is indeed the tricky bit, and it's inherently connected to doing new things.
Tutorials always look so easy, as they just code the program fluently in one go, without hesitation, and without (big) errors. However, what they don't show you is the 10 rehearsals they had to do before they could do it that fluently. In other words, they show a movie, the final successful result where everything runs smooth and perfect, rather than the entire path from literally no knowledge about the problem to that result. Unfortunately, reality works differently from a movie.
If you try something new, you're inevitably making mistakes. You don't have the experience yet to know what to avoid. On the negative side, things that look reasonable when you write it turn out to be blocking obstacles further in the process. Ideas that you had how things should work turn out to be large tar-pits of complicated edge cases that are not solvable. On the positive side however, some parts of what you coded do look ok, don't they? It's not that you have a blank file, type a single letter and think "oh, this is too difficult, I quit", right?
You're currently putting too much trust in your initial idea of how to solve the problem. When you get stuck, it's hard to break out of that situation, since you trusted your idea to be solid and it failed you!
The way out is to trust your code more than your idea. Ideas are nice, they show a direction and a very vague end-point, but they may miss major obstacles, or have large blank areas even if you don't see them. An idea is like pointing out a far away destination at a map. "There I want to go". At that time you haven't considered how to actually get there, which streets to pick exactly, checking there is actually a connection from street to street, and each street can be passed in the direction you want (and is not a one-way street in the opposite direction).
Coding on the other hand, is all about streets. In fact, it's about every single stone in every single street. No big holes between every two stones, are they sufficient level so you can move from stone to stone? street not flooded or jammed? Can you drive there? How fast may you drive? Do you have enough gasoline? If not, where can you get more? etc etc. All the little details you have to deal with when actually getting from A to B.
As such, a failure to code something is not about not being able to write code, it's about bad planning. Pointing at a destination wasn't enough, you should have taken more care in the details of the plan. The failed coding experiment is actually helping you here. At the point where you got stuck, there is something that breaks the plan you had. An unexpected barrier due to road works. It tells you exactly what in the plan was incomplete, and this is great. Instead of a very global "nah, you can't go there" without any explanation as to why, your code says "nah, won't work, as at that turn in that street in that city, you can't pass, since the 32nd stone is not level with the 33rd stone". This is very useful information, as you can specifically adapt your idea to work around that obstacle!!!
Time to get creative, adapt the plan, and try again.
Obviously, your coding abilities do make a difference. You'll find more obstacles on your way than I would, after 40 years of traveling. However, for both you and me, if coding fails, the plan is basically too complicated to achieve, we wanted more than we could deliver. Making the plan simpler is often a good way to make progress again.
