Hi @BurningQuestion,
Something that I see often in the forum is that people think using JavaScript, and that make everything more difficult(the usual recommendation in this case is replace JS with pen and paper).
The thing is, a solution is not the same as an implementation(in the implementation you have to fight numerous constrains). A good way to see this is read the posts(?) about the calculator project in the forum. An Example[0]
… I completely agree that this logic is difficult to understand
… In a nutshell I wrote that to solve the User Story #13 after a lot of trial and error.
I see, so your app evolved
, it was not designed. This is really common, IMHO is because most people write code “at the function level”, they write functions not systems. Another reason, is because they think using a programming language. The problem with that is a programming language is not the best tool to think[1]: it make difficult to express things that are often trivials with other tools, and the need to use a specific syntaxis can result in the waste of many hours fighting the language. Most of the time pen and paper is a better option. I really like to draw diagrams and tables for my apps, when I read code I have the tendency to try to “see” the logic of the programs, so is easier to use paper (maybe you can try to describe the logic of your app using other thing(not code, and it doesn’t have to be drawings)).
Also, the implementation of a solution in a programming language is difficult. Programming languages are opaque/unintuitive/verbose/imprecise[2] and most of the time you need to fight the language.
… if you have any more resources to study this topic, please share it here. ^^
-
According to wikipedia the article “Program Development by Stepwise Refinement” (about the teaching of programming) is a classic text in software engineering[3]. This is the origin of the recommendation: “divide the problem in small pieces”.
-
I really like the approach of the book “How To Design Programs”[4]
-
This talk is interesting “Design Patterns vs Anti pattern in APL by Aaron W Hsu at FnConf17”[5]
Cheers and happy coding 
Notes:
[0] Project feedback JavaScript Calculator
[1] Leslie Lamport: Thinking Above the Code:
[2] Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken – Google Research Blog
I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. Once I tell you what it is, you will understand why it escaped detection for two decades.
The bug is in this line:
6: int mid =(low + high) / 2;
So what’s the best way to fix the bug? Here’s one way:
6: int mid = low + ((high - low) / 2);
[3] Program Development by Stepwise Refinement
Programming is usually taught by examples … Unfortunately, they are too often selected with the prime intent to demonstrate what a computer can do. Instead, a main criterion for selection should be their suitability to exhibit certain widely applicable techniques.
Furthermore, examples of programs are commonly presented as finished “products” followed by explanations of their purpose and their linguistic details. But active programming consists of the design of new programs, rather than contemplation of old programs. As a consequence of these teaching methods, the student obtains the impression that programming consists mainly of mastering a language (with all the peculiarities and intricacies so abundant in modern PL’s) and relying on one’s intuition to somehow transform ideas into finished programs.
[4] Preface
[5] https://youtu.be/v7Mt0GYHU9A