A Programmer's Introduction to Mathematics

I think the choice to showcase the polynomial chapter is deliberate. The topic is likely to be familiar to many, but he's using it as an example to explain why mathematicians do things they way they do. I've often expressed the same frustrations that he describes when trying to explain to programmers why mathematics can't be replaced with a rigid programming language.

I think the author is confused. His book is not for programmers his book is for "programmers lacking computer science education" as computer science is a branch of applied match. If somebody says they have a computer science degree and they don't know math, I would doubt their degree.

For each section, start from the exercises, then work backwards towards the material necessary to understand and solve the exercises.

If there are no exercises, make some up (do the proofs yourself, try to come up with unsolved scenarios and solve them, etc)

For me it helped immensely when I had a fun side project that demanded new knowledge. For example, my chat bot side project was a fun way to learn natural language processing:

* its an "unsolved" problem (for various definitions of "solved"). I didn't expect to "solve" it, but every time I'd try something new there was the excitement that maybe, just maybe, this might be "it" (i.e. an immense improvement)

* the responses it produces can be really funny. If its online, others can have fun with it too.

* you can try lots of strategies and see the immediate effect. Not only do you learn about the math and technique by implementing it, but you get an immediate "feel" about the kind of effects it has.

Trying to over-generalize, it helps to have some "element" that you consider valuable, fun or rewarding to drive the whole process.

Holding my copy of this excellent book, I'm reminded of Mortimer & Van Doren's comment on 'How to Read Science and Mathematics'

249.2 "Until approximately the end of the nineteenth century, the major scientific books were written for a lay audience. Their authors--men like Galileo, and Newton, and Darwin--were not averse to being read by specialists in their fields; indeed, they wanted to reach such readers. But there was as yet no institutionalized specialization in those days, days which Albert Einstein called 'the happy childhood of science'. Intelligent and well-read persons were expected to read scientific books as well as history and philosophy; there were no hard and fast distinctions, no boundaries that could not be crossed. There was also none of the disregard for the general or lay reader that is manifest in contemporary scientific writing. Most modern scientists do not care what lay readers think, and so they do not even try to reach them.

Today, science tends to be written by experts for experts. A serious communication on a scientific subject assumes so much specialized knowledge on the part of the reader that it usually cannot be read at all by anyone not learned in the field. There are obvious advantages to this approach, not least that it serves to advance science more quickly. Experts talking to each other about their expertise can arrive very quickly at the frontiers of it--they can see the problems at once and begin to try to solve them. But the cost is equally obvious. You--the ordinary intelligent reader whom we are addressing in this book--are left quite out of the picture."

The authors apologize for not being able to offer specific advise to guide the reader of technical books, as those texts are on subjects of which they do not possess the necessary expertise. They suggest the reader fall back on 'scientific popularizations'.

I've found this to be a very useful strategy. Beginning with a readable book, well researched book. Then systematically read the book's bibliography, recursively.

The one problem I ran into, specifically in mathematics, was it seems some notations are not universal. Furthermore, some authors take no pains to define their symbols at any point in their texts. (I quite understand a paper would assume a specific audience, but for a published book I think it's just rude.)

For this I needed to rely on communities such as math.stackexchange.com.

Good luck. The journey is part of the reward.

This approach seems very similar to working backwards when trying figure out the behavior of a function that calls other functions or libraries and when trying to a debug an issue and following the stack trace to determine the root cause of the issue. Not a perfect analogy but I find it helpful to think about it that way.