Excuse me? Mathematics? I don't recall much of my K-12 math knowledge coming to play. You need to understand architecture to write simple programs that do useful things?
Of course you don't think that, it was just me being a passive-aggressive dickhead, but putting aside me deserving a punch in the face, mathematics is about patterns and flow and repetition and singularities and mappings and transforms and logic and states and abstraction. Every program written is an expression of mathematical thought.
Kludging around with numbers is to mathematics what paint-by-numbers is to art.
For me saying programming is tied to maths mostly is not a good thing: you'll be a better programmer if you studied linguistics, art, sociology and gender studies around your math classes.
Historically, programing has mostly been teached to science students but as we are currently talking about it, it will change maybe.
* There were always word problems. I had to take a few sentences or even a paragraph, and turn it into a representation that allowed me to get the answer. In later years this representation included variables that let me change some details and still get the right answer. Many of these had useless information included in the description, or were confusingly written, and I had to puzzle out the deeper model. This is not very different than taking a spec and making it into software. Particularly if you work directly with end users, who may include lots of unnecessary details. Sure the thing I build uses code rather than algebra equations, but that is not a huge leap - they are both mechanical rules that when applied to a problem give great, accurate answers.
* Speaking of variables - just learning variables and internalizing them is pretty damn useful for coding. This is not necessarily an easy thing to internalize - tutor some kids at basic algebra sometime. The idea that X holds a value seems pretty easy to grasp, but reasoning about X being any value[0] is pretty hard to grasp (until you do, then people say "i don't know why that was hard").
* Order of operations is another thing that was super important in k-12 math. Understanding that doing things in different orders gets different results is another big concept. It also leads to other operation ordering things - like doing things in a different order may be easier, and it's ok because they are equivalent (this is a huge chung of algorithms - do the steps in a different, equivalent order, and it's less work)
* Factoring in algebra and factoring in code are literally the same thing. Here is a list of variables and operations. Rearrange them into a different list of variables and operations using different functions.
* Substitution and systems of equations are pretty much the same thing. If y = x + 1, I can replace any Y with (x+1) and get correct answers. In coding we call this inlining and loop unrolling. Or even just replacing
$thing = func();
other_func($thing);
other_func(func())
* Cartesian coordinates are very helpful when doing any kind of page layout - like say HTML/CSS.
* Simple set theory is useful all the time too. Heck I even use Venn diagrams (something I learned in 2nd grade) all the time. Set theory comes up obviously in databases (and other data stores) join is just a method of computing intersections. But it also comes up in other places when defining things. A huge problem when designing systems is what I call the "square/rectangle" problem - all squares are rectangles but not all rectangles are squares. This is fundamentally a set definition problem - figuring out what set we are talking about based on certain properties applies to (but is not limited to): database schema design, object hierarchy, program scope, filter creation, and so on.
Looking at your comment again makes me wonder if you are questioning the Parent's semantics of "useful functionality" and "simple" vs "trivial". I'm not going to dive into that, but I will say I used many of the above concepts daily in simple shell pipelines (opening the semantic argument of what a program is, but going as broad as possible, a shell pipeline is a one off program that can be turned into a stored program by putting it in a file).
I regularly want to find something in a logfile. Logs have a lot of data. Oh, I can find the subset with grep.
cat log | grep thing
This is a trivial example of using composition, substitution and set thinking. I can extend it with "thats a useful search, maybe use a variable" and so on. Can this be learned, and done without having known the stuff taught in k-12 math? Maybe I don't know, but the place I first encountered and internalized those concepts is math class.
Even more controversial (from the is this a program point of view) is that these things are all useful in doing excel formulas and vba scripts.
[0] I know that's not strictly true, particularly with types in a computer language. But they taught me about domains, and things like "this is true when X is not 0" and so on. This translates well to code too - checking that values are acceptable in tests and input sanitization, or conversely, finding weird values by fuzzing are all applications of domains.
Learning needs to be holistic; you fill the gaps as you go.
I'd also say that programming is a mathematical endeavor by nature; logical manipulation is a branch of mathematics. If you're working at a level of abstraction where you aren't specifying logical manipulations, then you're filling out a template, not what I'd call "programming".
I learned basic trigonometry early (with a textbook and some advice from a school mathematics teacher) for the purpose of rotating vector graphics in BASIC to make a Spacewar clone. I expect there are many people who learned about complex numbers because they wanted to draw fractals. And linear algebra can sound boring until you realize how useful transformation matrices are in graphics programming. Programming is a great motivation for learning mathematics because it's so much more fun when you have mathematics skills.